This JIRA is about about splitting up the settingshandler portion of the system configuration into two parts. Currently, we read the settings as we write them - as one action. And if we crash partway through writing the settings, we wont have recorded the original settings and hence leave the system corrupted without an ability to restore it. What 4b is about, is splitting that action into two: first read the settings from the system (and store them), then start writing the new settings.
Besides actually splitting the settings application into a distinch "get" and "set" part, this work involves insuring that the settingshandlers have a proper "get" implementation (a lot of them are either un-implemented, un-tested or doesn't follow the correct API.)