...hitting command-Z to remove the color tags did not do so, but reopened a previously closed tab.
This seems to be a function of how Safari's multiple undo feature works, in conjunction with how you applied the color tags. Selecting a snippet of text and then using one of the the UBB shortcut buttons to apply tags to the selected text does not constitute typing, since the application of the tags is accomplished via Javascript.
Therefore, Command-Z does not invoke
Edit ->
Undo Typing, but rather invokes
Undo [whatever the previous undoable action was]. If, say, you have two reply windows open, you type something in window 1, then type something in window 2, then apply color tags to what you just typed in window 2, then hit Command-Z, you'll Undo Typing all right—but it will be the typing in
window 1 which gets Undone!
I know you disdain mousing through menus in favor of using the keyboard, but you can make all of this (slightly) clearer by examining Safari's
Edit menu after each action you take, to see how the object of the
Undo command changes with the context. In the case in question, your previous Undoable action was to close a tab, so once the Javascripted tag application disqualified typing as the most recent Undoable action,
Undo Close Tab became the command invoked by Command-Z.
As for why if you type some, then type some more, then apply tags, the
earlier typing doesn't become the object of the
Undo command, I think it's that the Javascripted tag application is interpreted by the browser as a species of page reload, so that any earlier Undoable actions are whisked into oblivion as having been taken on a no-longer-existing page. (See
Ajax (programming) for some sort-of-related discussion.)
Note: to rule out the possibility that this Undo behavior was unique to FTM, or more likely, to UBB.threads, I did some experimentation at MacOSXHints, which uses vBulletin software. Results were similar.