It might be useful to clarify the expected behavior of background colors on nonstandard screen borders (i.e., the negative space around the text windows by interpreters like Gargoyle or Parchment, or screen borders such as those on the Commodore 64 - not the Version 6 window margins). This was relatively unimportant in the early days of fullscreen terps, but is now a significant player-experience consideration for some games.
Interpreter behavior is inconsistent. Parchment sets the border color on executing @erase_window 0 (CLEAR 0), effectively matching the border color to the color of the lower window. This seems like the most sensible expected behavior. Gargoyle, by contrast, does not respect the background color when executing @erase_window at all (which actually seems like a bug); instead, it sets the background color of all windows and borders to the current background color when an input opcode is executed (@read, @read_char). In practice most games with non-default background colors will both clear the screen and subsequently wait for input before changing the background color again, giving either approach similar results, but the inconsistency could cause issues for any particularly psychedelic usages of color.
Proposal: add a sentence to §8.7.3.2 reading something like “For interpreters that display additional whitespace around the game windows for layout reasons, it is recommended that erasing window 0 also set the background color of this whitespace.”