Interesting. I see your point. I suppose I don't consider this very much because from my selfish point of view, my application only runs in 1 of 12 "fully built" themes that don't rely at all on any system defaults (AFAIK).

It makes me wonder if FLTK is aware of whether any "system defaults" are still "in play" or not. If FLTK is capable of being aware of this, then perhaps it could be more "hands off" and not meddle with theming as much when there are no more "unpredictable" system defaults. (ie, only compensate for poor contrast whenever a system default is the culprit.)

Of course, if FLTK is not already capable of making this distinction, then this is only a hypothetical suggestion; not a very serious one.

But I do think there is value in letting the user developer have the option to take the responsibility of ensuring the theme has adequate contrast, and in return FLTK will not tamper with it so much (except, for example, in the "obvious" cases like simply making sure foreground text contrasts with the background which is virtually always desirable).