With the caveat that I’ve barely touched the color code in Gargoyle, I think what’s happening is this:
When you call garglk_set_zcolors, Gargoyle sets global color override variables (gli_override_fg and gli_override_bg). And unless an individual character has its own color set, when the screen is drawn, those color overrides are used.
So the color works in Gargoyle because of this sledgehammer approach: when the upper window is drawn, it inherits the global colors, regardless of when they were set. It also means that colors don’t work quite in accordance with the standard says. Gargoyle is too optimistic, let’s say, in setting screen colors.
Way back in the days when Gargoyle was hosted on Google Code I reported a bug around this very issue:
I haven’t put much effort into this bug since things have been “good enough” with games that use colors. I guess SameGame, as I noted in the bug report, is one that does have issues…
I think part of the problem, too, is Glk’s window model vs the Z-machine’s… @erase_window -1 should set the whole screen to the current background color (which is global, not per-window). Then when the upper window is opened, it’s already the background color since Z-machine windows are just “viewports” into the current screen. But Glk’s window is an actual window. So when it’s split, it should have the same background color as the current color. And if I had to hazard a guess I’d say that requirement is why Tor Andersson implemented colors the way that he did. Because it works well enough, I suppose, for the majority of use cases. It fakes it: the current background color is just used everywhere unless text has already been written in a specific color.
There is probably a better approach to all this, but I’d have to give it some more thought.