I would like to see a simpler approach that may still be effective in
Kernel images with the minimal of scafolding, and I am still slightly
edgy about pragmas. (can anyone remember how Smalltalk Agents used to
use "directives"? I cant, but I seem to recall they were a similar idea).

Here is an idea:

Have classes PreferenceDefaults, PreferenceOptions, and
PreferenceValues, and have your package add method extensions to it. So
Monticello adds

PreferenceDefaults-#prefUseAtomicLoading

    ^ true


PreferenceDefaults subclass: PreferenceValues-#prefUseAtomicLoading

    ^ true

PreferenceOptions-#prefUseAtomicLoading

    ^ {

    'Enable atomic loading' -> true.
    'Disable atomic loading' -> false.

    }

If you want to subclass PreferenceValues, for PreferenceUIValues, so
that a number of your UI  packages become aware of PreferenceValues ui
prefScrollBarsOnRight (still use only one global in your client code if
possible)

Implementers of #prefUseAtomicLoading tells you all there is to know, -
who defined it, default value, possible values, current value.

You can save the preferences form the image in a file out of the class
Preferences.

If you have a subdomain that wants to use different values, define a
subclass of PreferenceValues, and inherit the defaults and current
setting, or inherit PreferenceDefaults and provide your own, (overriding
#ui to return ^self if you want to provide values for the
PreferenceUIValues).

You can easily have one preference depend upon the value of another, or
upon simple rules.

PreferenceDefaults-prefUseAtomicLoading  ^ (Smalltalk classNamed:
#SystemEditor) notNil

In this manner you have a preferences system which needs "no code".
Discovery is a simple walk of the tree of PreferenceValues.

If you want to watch for preference changes, you can simply subscribe to
whatever system changes modification event mechanism is in place.

Keith