UIOptions handling of its default options has always been very brittle. Until the https://fluidproject.atlassian.net/browse/FLUID-4531#icft=FLUID-4531 work, this was held in a central static location as part of the defaults for the SettingsStore component. Even in older days, this caused some problems - when upgrading from one version of UIOptions to one which managed more options, the component would malfunction until the user cleared their cookies - since the defaults record was only used in the case the cookie was empty. Finding any cookie at all would bypass the defaults, presenting the component with some options which were "undefined" and would so not render properly. The component was effectively unusable in this use case.
Just before https://fluidproject.atlassian.net/browse/FLUID-4531#icft=FLUID-4531 as part of FLUID-4607, I (AB) made a change to the store algorithm to always merge in the defaults before returning them. This resolves the issue described above, but introduces a different problem. Now UIOptions stores every option back into the store, including those derived from the defaults, and so in the case the value of a default changes between releases of UIOptions, a user will continue with their originally stored value of the default, even if they didn't make any change expressing a preference.

We need to rethink this architecture before too long, especially since https://fluidproject.atlassian.net/browse/FLUID-4531#icft=FLUID-4531 antification will lead to UIOptions being used in increasingly flexible situations. For now we should just fix up the tests which were invalidated by this change in semantic. A promising architectural scheme for meeting this issue might be to take advantage of the new "source tracking" facility in the ChangeApplier to distinguish which changes are caused by the user and which from a store fetch.