I have tried 1.47-C, 86efbd6. I haven't been able to get a desync anymore. Well done.
Remaining is 2 bugs, and 1 design question. I'll post them in this thread, because you posted 86efbd6 in this thread, and it's particular to that.
1. Assign something.
2. Framestep back to the frame right before the assignment is carried out.
3. Double-click nuke, then unpause.
Observed: The assignment is carried out, no nuke.
Expected: The assignment is cancelled, instead we get nuke countdowns.
Setting the RR removes from the replay all future assignments, except the assignments for the very next frame. I don't know if this is intended or not. While you don't allow multiple assignments per frame, you allow 1 assignment, 1 RR change, and 1 nuke at same time. Example: The replay has saved commands A, B, C for the next frame, and we input command D for that frame, and then we input command E for that frame. I want D to remove A, B, C from the replay, but we don't want E to remove D. The Lix solution is that D and E go into a special waiting room, and will be only written to the replay right before the update happens, when no more player input can arrive.
Please specify the expected behavior for this corner case. :-)
Sometimes, you show the R, even though there is no replay data in the future, and sometimes you don't show it, even if there is data. I can find out more details for this bug. I suggest that you don't make a status variable for the R, but instead make it a purely functional dependency.
-- Simon