I’m not sure what changes happened post-v6 (other than more RTF richness) but my understanding is all $Text-related attributes are inherited in a not until any styling, even be it a bit of bolding is applied. At that point all $Text hard-encodes its values, even for runs of text that the user would presume as 'default styling. Why? I don’t know but I’m sure it seemed—some years pre OS light/dark mode—a sensible approach. Anyway, even if the ‘default’ text toggle text/background colours, what about the bold purple text on a lime green background you set in a moment of hilarity? Even if we don’t care about those edge cases, the developer has to - even if only to pragmatically ignore them. If tempted to say “But, Apple apps…” see Howard Oakley’s blog for even Apple can’t properly handle its own invention.
I too tend to switch, with the result I gave up on dark mode. Sure, it looks cools, but I don’t have the 20/20 vision of my youth and everything reversed out is either too contrasting or has not enough contrast. I found I’d run in dark OS mode ‘chrome’ but choosing to have a ‘light-style’ view and text background—pity the poor dev. So, I’m back in light mode. Meh.
I agree things could be better for (colour) swingers. So the question is, what do we expect to happen to the $Text pane on mode switch. My thinking is, if we users can’t easily describe it (in terms of current settings/attributes) it might just harder than we imagine.
This is the point (and this isn’t a come-on) where @eastgate de-cloaks and points out my reasoning is flawed and this is easy to do. (thuogh possibly ont in a tist of global pestilence).