When you made the savestate, was the jumper already in the replay?
Whenever you stateload: The snipping sound plays because stuff in the active replay is discarded -- unless the stateloaded replay is an initial segment of the active replay, then we keep the active replay and no snipping sound plays.
Here's a scenario in which save+load3 is bug-free in 0.9.9 design:
* Dig in frame 100
* Jump in frame 1300
* Framestep back to frame 500
* Savestate in frame 500
- Savestate's replay has (100 digger, 1300 jumper)
- R in corner is visible (Reason: future assignment of 1300 jumper)
* Begin video capture
* In frame 550, load state.
- Active replay stays active (Reason: state's replay is identical to active)
- No snipping sound (Reason: Active remains as-is)
- We return to frame 500
- Active replay is still (100 digger, 1300 jumper)
- State's replay is still (100 digger, 1300 jumper), same as active
* Implode at frame 700
- This cuts (1300 jumper) from active replay (Reason: 1300 is in the future)
- Snipping sound plays (Reason: We cut something from active replay)
- Active replay is now (100 digger, 700 imploder)
* Load the savestate.
- State's replay is still (100 digger, 2000 runner)
- State's replay overwrites active (Reason: State's replay isn't initial segment)
- Snipping sound plays (Reason: We cut (700 imploder) from active replay)
- Active replay is now (100 digger, 1300 jumper)
- If we wait until frame 1300, we'll see the jumper play back
I can't be sure since I don't understand the bug, but I doubt the slow machine affects the correctness of the algorithm.
It doesn't seem to desync anymore with the method I found.
To preserving future: The case mentioned in the issue shouldn't work this way anyways since rewinding before an action cancels if you don't keep replay (, unless you've meant A,C instead of A,B in the end?). But you've mentioned another case in the thread, where you load instead of framestep back. Well loading cuts now all out what doesn't belong to the savestate (even if you have keep replay on and it's after the savestate), so with that the future replay is discarded as well.
if you have (option: keep replay when rewinding) on there is still a possibility to have future in the savestate: By framestepping back before an action and then saving.
Well and one new desync problem: If you go to a phyu before the save now and cancel an action of the save you have to press load twice to get the actions of the savestate in the replay. If you only press once you get the savestate but the action isn't in the active replay.
Video attached.
Edit: Just for clarification: The new desync is a matter of the unstable build.