Sure, but is that implied by "reify"? My understanding is that they are reified and thus it is possible to make a timeline from them. CLI commands are only recorded into a timeline because of shell history, after all--if you call a CLI from a different mechanism, does it become not-reified?

The underlying commands can still be logged.

Hell, often it is useful to launch a X11 program via a terminal as they will dump useful messages that way.

And said output can also be captured in logs elsewhere.

One example of such would be SMPlayer. This is a Qt based media player that wrap MPlayer (and more recently the MPlayer fork MPV). But you can still access the MPlayer CLI output by either launching SMPlayer from a terminal, or going opening the log window from one of its menus.

To be clear, this was my point--because of the "action" mechanism, it's trivial to make a timeline.

The undo stack of any document oriented application is that timeline? Typically if you hover the undo button it says "Undo add frob" and if you undo that, you can see the next item. It's also common to be able to drop it down and see the whole undo stack and undo to an arbitrary point in it.

Since this has been par for the course for for as long as I remember, I take it that's not what's discussed here...

Many apps (or app windows) have actions, but not undo stacks. Undo stacks are typically only used in app windows that display a document of some sort, and then the stack is limited to actions on the document. Have fun trying to revert the last 10 app configuration changes.

Right - the undo stack is always for a "document" of some kind, and more importantly a single user view of a document. Multiple documents can be used (with a single or separate undo stacks) and a settings object can in theory also be viewed as a document although this is rarely the case.

A manager once asked for full undo in a GUI for a shared db. That's not possible...

My point was that if actions are dependent and undoable then they form a stack. If everything can be undone then all that you are affecting (including view state, config, ...) has simply become part of the document.

In the app I'm developing I'm distinguishing "actions" as being what a shortcut/button/menu item represents and "commands" as being document modifications.

Actions aren't necessarily undoable ("quit" is an example) but most actions end up as being commands, and those commands form the undo stack. Actions handle availability (enable/disable) etc. I think this is a fairly standard pattern for document based applications.