> ScrollPanes should not have any knowlegde about SystemWindow. So storing the
> preference in SystemWindow >> #backgroundColor is not an option.

+1, but that is tangential to our discussion at the moment -- we just
want to establish our "design" for enabling the ability to have
different color sets.

> It would make sense, however, to attach individual preference to those major
> widgets. So that ScrollPane has its own #backgroundColor.

Use-case #1 is:  I'm working during the day, I want a brighter,
black-on-white scheme, when night comes, I want to "one-click" switch
to a white-on-black scheme **without changing or having to
double-manage** any of my other Preferences in the system -- they
remain untouched.

I'm concerned that individual preferences scattered across a bunch of
global class vars would inhibit my use-case above.  Are you saying I
would have to go into Preferernces panel and change the 30-50
"individual preferences" to go to night mode?  To have "color themes"
someone would have to write a methods to update all the globals,
something like this:

    ScrollPane backgroundColor: ...
    ScrollPane foregroundColor: ...
    SystemWindow titlebarBackgroundColor: ...
    SystemWindow titlebarForegroundColor: ...
    UserDialogBoxMorph backgroundColor: ...
    UserDialogBoxMorph foregroundColor: ...

And what package would such methods be written in?  They have to
reference the entire system, so there would be dependency issues.
Every time we discover a new thing needing color we'll have to update
this method...

That's why I think we store colors into ColorSchemes which can be
swapped out whole and grow organically instead of a bunch of
class-vars.  I don't care about exact the implementation details, just
that we make something flexible and easy to use and maintain, not
brittle.  Please.