The way most software I've seen resolve this is to have a defaults config file and a user config file. defaults is defined by the application maintainers and the user config overrides any settings in the defaults.
So you can do updates to the defaults but if users wanted to specify specific customisations those would be preserved. Also users can browser the defaults config and copy/paste chunks of that config into the user config file.
Those files are often named differently and/or located in different parts of the file system hierarchy; but the concept is the same.
right now, configuring workspacer is a very imperative, mutable process, because you just setup instances of objects, and call functions that setup some state. some care would need to be taken to design an API that could be "layered" in that it could be easily overridden by the user. this is a good idea!
Might be just as easy as making sure that all of your defaults are documented in the doc-comments of relevant properties and encouraging people to use CSX editors that have good documentation tooltips for API exploration (like VS Code with OmniSharp)?
So you can do updates to the defaults but if users wanted to specify specific customisations those would be preserved. Also users can browser the defaults config and copy/paste chunks of that config into the user config file.
Those files are often named differently and/or located in different parts of the file system hierarchy; but the concept is the same.