Seems like it's something like that he's going to try out.
While unfamiliar with Renpy, I can assume there's significant issues with that as well because certain values will still yield different outcomes. E.g. you're at the end of the game and have "lovepoints = 50;" you then jump back to scene 20 and there is a discrepancy of potentially 50 points. So he'd need to save every choice and then systematically emulate the steps back to scene 20 or alternatively store the variables at certain checkpoints for later usage. The first solution is ass while the second is striaght up twice the ass because what do when you create new save games? Yea, suddenly you need 5000 tables for 10 gallery scenes.
Changing any of the prior story's order would require updating the stored routes/selections so that means writing an updating script that would also break every couple updates (because that's just how it is).
Not to mention any kind of debug editing of variables would yield a bunch of errors meaning more people crying about things not working (sure, no need to address them, but they'd still be there).
If I was developing a renpy game I'd just say "haha lol, no, suck it" to any kind of save->gallery permanence. I'd wager less than 10% of people even use the gallery and even then only a fraction use the feature more than 5 times. It would be a massive waste of time unless it would be for the fun of making it and then abandoning the feature in the next release.
Edit: After thinking a bit more, a good and easy to implement solution would be to just create a separate save game at certain checkpoints when the gallery event occurs. When loading a gallery scene (save), you'd also set a "gallery = true" variable which would tell the game to exit once reaching another checkpoint.
Then whenever you hit the checkpoint again in a different playthrough, it'll overwrite the gallery scene (save).
The gallery scene selection view would just be a gallery scene (save) loading view.
Super simple solution if it's possible to create multiple save views. Obviously more work than it's worth, but would actually work, be very compatible and wouldn't be excessively difficult to implement.