to fix this number in the title of your jumper skill shadow bug report then 
Changed 12.5.5 to 12.12.5 in
NL jump arc shadow topic, thanks!
you want this out of habit, regardless of why NL 12.12.5 has it in this surprising way.
annoying to hold down the rewind 1 second
Right, I see why rewind-to-previous-assignment is useful.
With "you want this out of habit", I meant: When NL rewinds to before the assignment, why do you consider it natural/desirable/correct/... that it rewinds to
exactly 2 ticks before the assignment's effect (1 tick before the click), and not to the immediate tick before the assignments effect (the tick of the click).
I don't question the usefulness of rewinding to
some tick near the assignment.
This can work too. I'm fine with seeing your idea of the behavior implemented, and again can be another thing that Lix does differently from NL 
Okay, I see now that you don't mind as much exactly how far before the assignment it goes.
I think I'll keep the rewind to the tick immediately before the visible effect of the assignment, then. If you begin to miss some deep importance of NL's behavior, let me know.
this is a leftover bug workaround.
I disagree about it being a bug.
By "bug", I didn't mean this rewinding behavior.
I called this a
workaround for a different bug, and that bug was:
LMB advances physics before cancelling replay. This has long been fixed. I reported it in 2016-02 and namida fixed it around middle 2016.
I didn't dig for the history of the rewind-to-previous-assignment in NL. I merely remembered that I filed that replay-cancelling bug. It's possible that rewind-to-previous-assignment is entirely unrelated to that replay-cancelling bug.
Then why do I bring this history up at all? I copy a feature from NL here. It's possible that NL's rewinding to precisely 2 ticks before the assignment's effect is somehow really useful/natural/smart/..., compared to rewinding to the immediate tick before the effect. What importance might I be missing when I implement it in Lix to rewind to the frame immediate before?
The main deeper meaning I can imagine is: Rewinding to 2 ticks before the assignment would have been useful when NL had that replay-cancelling bug. Under that bug, and under NL's rewind-to-2-ticks-before-assignment, you can { activate that rewind, then left-click to cancel replay } and still see the replay cancelled; compared to being under that bug, but with Lix's proposed rewind-to-1-tick-before-assignment, you would { activate that rewind, then left-click to cancel replay }, but thereby run into the bug where NL replays the unwanted previous assignment that you didn't see yet on screen, but you wanted to cancel with the left-click.
Since Lix hasn't had such a replay-cancelling bug, I don't need that workaround.
The second possible reason is that NL's rewind-to-2-ticks-before-assignment makes it easier to pull the assignment exactly one tick earlier (omits need to use the 1-tick-rewind before reassinging), at the cost of unnaturality of the feature. If this is your only use case, I recommend the tweaker. It's designed to do exactly that: Tweak assignments that were mistimed by a few ticks.
Given that I could have recommended the tweaker in the first place, why do I still jump on this opportunity to implement rewind-to-previous-assignment at all? The answer is: I've considered to add this functionality to the tweaker, too: Click on an assignment line in the tweaker to skip/rewind to the time of that assignment. Now, suddenly, you want this even outside the tweaker, and you have lots of experience with that feature to boot. I'm considering you the expert for this. If I deviate from exactly what you know (exactly to what tick around the assignment to rewind/skip), I'll better know what I'm doing.
That's the reason why I'm making this discussion feel like pulling teeth.
-- Simon