I think I've got it fixed, but will need to test it some more.
To be specific, it happens if you assign a skill on the exact frame that the timer goes from "xx-x1" to "xx-x0" (on a time-limited level). If you were to then backwards step before reaching the next 10 second mark, the skill assigned exactly on that frame will still be in the replay, but will not be reflected in the on-screen state (including in terms of physics and skill counts). If you were to backwards step past the faulty 10 second mark, and let it play from that point, the skill will occur as normal.
Chances are that a proper fix for this would need rewrites to how each frame's updating is handled, similarly to how
this issue does. So instead, I just coded a workaround that detects the conditions that trigger the issue, and if they're detected, it'll use an older saved state for backwards framesteps. (The more-logical thing to do would of course be to not make the save state in the first place, but this too would've taken a lot of change to the code, compared to the relatively simple change for the ignore-faulty-saved-state method.)
I don't think it's possible to ever have
no acceptable save state (since I don't think it's possible to assign a skill on frame zero), but just in case, there's fallback code to ensure proper functioning even when no earlier saved state is available.