Ideas for extending options to track user-changed options separately from system options so as not to override unchanged system options.

I was inteding on implementing this, until I realised the extra complexity necessary. Also the gains in functionality seem tiny and not always desireable.

Extract of doc. plus example:

/** Base class for handling options. This class itself will handle no options and should not be
* instantiated, but sub-classes handle options.
*
* Each sub-class provides named variables for maximal-speed reading; however these cannot be used
* for changing options due to only changed options being written to the user file.
*
* The static class keeps track of all Options class instances for global loading and saving.
*
* Details: Options sub-classes hold associative arrays of pointers to all options, with char[] id.
* When options are changed, they also load all options from the user file to save back there.
* When an options GUI window is opened, option names and descriptions are loaded using the id and
* i18n.I18nTranslation (possibly not by the Options class), and possibly also system-level options
* are loaded to allow users to revert to these.
*/
class Options : IDataSection
{
    bool example;
    
    bool*[char[]] optsBool;
    bool[char[]] cgdOptsBool;
    bool[char[]] sysOptsBool;
    bool changed; sysLoaded;
    
    this () {
        optsBool = ["example":&example];
    }
    
    ...
}

From todo.txt:
Options:
->  types:
    ->  bool
    ->  int
    ->  char[]
    ->  float/double/real?
->  automated saving/loading
    ->  track whether any options have been changed
    ->  track all changed options (minus ones reverted to system confif) plus all options loaded from file to save to
->  symbols (static or associative arrays?)
    ->  read-only outside of class
    ->  a merge of "changed" and "system"
    ->  only part which needs to be loaded when not changing options
->  "Changed" symbols
    ->  constists of entries as above (changes above system config)
    ->  only loaded when an option is first changed?
    ->  use setter functions
        ->  change/add/remove from "changed"
        ->  change base symbols
->  "System" symbols
    ->  symbols only loaded from system-level config
    ->  only to show what the default setting to revert to is (since otherwise when removing a user change its system value wouldn't be known until config is reloaded)
    ->  only load when required
->  sections
    ->  one class per section
    ->  classes may be derived to provide their own handling
    ->  use separate files? Otherwise cannot efficiently load options on a per-section status with mtt files.
->  root or static class
    ->  parent of all sections
    ->  handles saving and loading