Two design choices define how undo behaves here, and both come from the same observation: the moment you need undo is usually not the moment you made the change.
Persistence. Undo and redo are stored as files with a versioned schema rather than held in the running process. Each stack keeps up to 25 records, pruned oldest-first past that. Because it is on disk, closing the app and restarting the machine do not clear it. That directly addresses the realistic failure case — noticing days later that something is missing — which in-memory history structurally cannot cover. It also means the history is inspectable: the interface shows how many points are available in each direction and a label for the most recent, so you can see what you are stepping back into.
Replay rather than assumption. When a change is applied successfully, its inverse is recorded. Undoing does not assume the inverse will apply cleanly; it runs it through the same write path an ordinary apply uses, against the registry as it exists now. This matters because the world can change between a change and its undo — an application can be uninstalled or updated, a key can be locked by another process, an entry can now be protected. Running through the normal path means those conditions produce the same honest reporting a normal apply does: per-entry fault isolation so one locked key does not abort the rest, and a count of what Windows refused rather than a blanket success. Blind replay would report success and leave you with a state that does not match what you were told.
The write path being shared has a second benefit: the operations are idempotent. Undoing a change that has somehow already been reverted is harmless rather than an error.
After a successful undo, the record moves onto the redo stack, so both directions are available and both survive restarts. Applying a new change clears the redo stack, which is the conventional behaviour and avoids a redo that would conflict with what you have since done.
Undo and snapshots are complementary rather than redundant, and it is worth knowing which to reach for. Undo is precise and step-wise: it reverses specific changes in order, and it covers every change the app makes, including areas the snapshot does not span. Snapshots are broad and point-in-time: they return a whole area to how it looked at a moment, regardless of how many steps happened since. For a single regretted change, undo. For "put it back to how it was on Tuesday", restore a snapshot.
