Thanks for the suggestions. All four are large endeavors, and I'd attack them in this order:
Replay management: This can improve in small steps and is the easiest, even though I have to make GUI, which takes long to get right. For a selected level in the singleplayer browser, the game should offer all replays installed in the standard replay tree. On manually saving a replay, you should optionally enter a name that overrides the timestamped default name. Replays should be movable/renamable from the replay browser.
Skill blueprints: This can also work in chunks, with a dumb implementation at first that merely draws a diagonal line under the miner. More powerful blueprints would simulate physics and then visualize the result somehow without really drawing permanently to the land; this might be tricky to make efficiently. We'll see.
Undo: The original idea was to use the object-oriented command pattern for this, but the code is expensive to refactor towards this. If I make this, it'll be a naive implementation with lots of savestates. We'll have to measure RAM, but since these savestates (levels) won't eat any VRAM, there should be no swap-to-RAM-then-crash here.
RAM crash: This is the hardest to fix because, to my knowledge, I must hack the VRAM map apart into several VRAM bitmaps, and then savestate only the changend parts. This will touch a larger chunk of already-complicated code. I'm considering to defer this because our workaround -- avoiding gigantic maps -- is sad, but at least it has prevented all crashes during the 2018-03-11 session.
-- Simon