Maybe, maybe not. My understanding how Renpy saving/load works is this: on load it can't go back to the same byte location in the .rpyc as that may be a different point in the current .rpyc. It can only go back to the last label it passed before the save was made and then execute forward from there until it encounters a stop point, like displayed text or a button to hit. Everything between the label and the stop point is executed, including maybe a random statement. This behaviour also explains why a save can become unusable. If that last label is not in the current .rpyc Renpy has no idea where to go and it fails.
Based on my understanding, you described it really well.
I have changed files and created new ones, rearanging the code for 0.2.0. This probably made it a lot worse compared to previous updates.
A save bet is to create a save when not inside a scene/event/appointment. So when you are in your room or any other location and nothing special is going on and you have the menu on the right visible.
Saving from there poses the least problems for Renpy. If you want to be sure, don't save when in the new player room, because it is kind of a scene in itself. Use another lcoation.
In addition to the logic described above (finding the "where do I have to continue" for renpy), there is also the problem of where to return to.
My game is modular, and every scene/even/etc. is inside a "function" that is called. You leave the function with a "return" statement. Most scenes can be called from various places. Since the "stack management" in Renpy can't be byte/address oriented, it's adding call from <origin> to every call statement so that it knows where to return to. These <origins> are auto generated when you compile teh game for release. So if something is different, or the <origin> doesn't exist any more, when coming upon a "return" statement, Renpy doesn't know where to return to.
That's why some saves cannot be loaded and you get an error about missing or unknown "return" or don#t know where to return to or similar.
