In a game that uses non-default text/background colors, UNDOing after a full-screen-color-change will result in "islands" of the old colors on a screen of the new backgound color. This works in contrast to systems like TADS where changing the background color can be done without clearing the screen. The way Hugo handles it is not necessarily a detriment; I have an idea for at least one game idea that wouldn't work if Hugo worked the other way.
Still, it introduces an interesting dilemma- is there a way for the library to handle such UNDO situations in a non-obnoxious manner? I've been thinking about this since yesterday.
Instead of trying to design some complicated word-array-saving technique to keep track of colors (as the word array is one of the only things not affected by UNDOs, RESTOREs, and RESTARTs), I eventually decided that the best way to handle this will be to write a configuration-file-writing library extension. All of the Hugo ports that I know of that support color also support configuration files, anyway.
The hardest part will be deciding what kind of naming scheme I want for the configuration file so it plays nicely with other games that use the same extension.
Anyhow, when it's written, it should be appreciated by color-lovers and color-haters alike (as it will also give players options to "opt out" of color changes).