If needed, I can build and upload executable files for testing. (Linux, macOS only)
Let me know if you need it.

Yes, it might be of interest, so more people can give it a try.

Not using transactions?

Yes and no. We are using savepoints, which are a special kind of transactions that can be nested. We use them for the editing in the data browser. On the other hand, we are using a transaction for the SQL code executed by the user in the "Execute SQL" tab.

I can see an issue if random items are undone so the history may need to be sequential. I would have to ponder this a bit more before offering something more than observations.

I'm not sure if I get what you mean. Let me explain how this is working.

Looking at the code, it seems like the original developer wanted to avoid repeated identifiers for savepoints, but in SQLite, savepoints are stacked and allows repeated names. When you release or rollback to a savepoint, the most recent one is released or rolled-back to.

I only change the minimal code to allow the undo savepoint to be repeated, and then it can be rolled-back gradually using "Undo" actions.

What I'm seeing now is that the original RESTOREPOINT savepoint which we used for "Write Changes" or "Revert Changes" is now useless, because all the changes are either committed or rolled-back when the final DB4S_UNDO savepoint is managed. There is probably a cleaner way to implement now all the savepoint management. Maybe the original developer was not aware of how SQLite manages repeated names in savepoints.

I think we could either use only a series of undo savepoints, and then we can release/rollback-to all of them on "Write Changes" or "Revert Changes" (this is what is done now in practice, despite having RESTOREPOINT), or we have a global RESTOREPOINT, which is the only one needed to release on "Write Changes" or rollback-to on "Revert Changes"; and accumulating DB4S_UNDO, which can be individually rolled-back to on each "Undo" operation.

But in its current state seems to work fine, and it would be only a matter of cleaning code, which in fact seems to have never been needed (like uniquefying savepoints and releasing all savepoints, instead of releasing the first set).