Saved "Default" settings not appearing next to custom settings

Development
1

Problem: When custom settings are added, un-altered defaults are lost.
Context: My get_settings_defaults settings contain a dict (statusDict) as per below:

statusDict={
	'Connected' : {
		'colour':'#FFFFFF',
		'brightness':'255',
		'turnoff':False
	},
	'Disconnected': {
		'colour':'',
		'brightness':"",
		'turnoff':True
	}

My plugin allows this dict to be expanded with additional statuses (e.g 'PrintDone' with its own colours etc).

If no custom statuses are added, self._settings.get(["statusDict"]) returns all the default values as expected.
However, when a custom status is added (e.g 'PrintDone'), self._settings.get(["statusDict"]) ONLY returns this custom status, instead of the defaults + custom.

When manipulating statusDict in the front end, I am rebuilding statusDict to include the new entry along with the old, and sending the complete dict back to the settingsViewModel.
Looking at statusDict in the front end shows the complete dict

Impact
My plugin tries to match events against statuses in statusDict. Adding a custom status prevents the statuses in the defaults from being used even though they "exist" in the users settings page.

Expected behaviour:
As the original default values have not be removed or altered (only added to) self._settings.get(["statusDict"]) returns the original and new values.

Armchair opinion
The docs say

Values identical to the default settings values will not be persisted

I assume this means in config.yaml and indeed when i add a status, only this is present

statusDict:
      PrintDone:
        brightness: '255'
        colour: '#1722f3'
        turnoff: ''

The symptoms suggest that the dict is being diff'd with only the added section persisted, and if there is a key for the setting in the yaml only this is retrieved by _settings.get. Which makes sense as having a single source of truth for a particular settings key allows the defaults to be overridden

While it runs contrary to the docs, it feels to me like the correct behaviour in this instance would be to treat the entire statusDict as a single setting that if altered, the complete updated dict is persisted to yaml

Please see the develop branch of my repo for full code if relevant https://github.com/entrippy/OctoPrint-OctoHue/tree/develop

2

I have found a little bit of a work around, but it feels a little hacky.

I've set the default for statusDict to Null, and in on_after_startup if statusDict is still Null, I am injecting bootstrap defaults as a suggested starting point. With that done and the complete dict now persisted in yaml, end users can manipulate them as they see if.