It seems that the general schema for changing settings related to the Windows Magnifier includes a restart of the application (in order for the new settings to be applied). This is fine for settings like "Magnification" and "Magnifier position". However, if the user changes the "Magnifier Enabled" value to be "Off", then Windows Magnifier should simply close and should not restart in this case. This will require a special handling for this particular setting. If this turns out to be too difficult, a workaround can be to simply remove the "Magnifier Enabled" setting from the payload sent to PCP (assuming that if the user wants to disable magnification, he can do that by setting the "Magnification" to 1).
Another thing which should be considered when the "Magnifier Enabled" setting is "Off", is what should happen if the user wants to change other magnification related settings (e.g. "Magnifier position"). In that case Windows Magnifier should probably not start or if it does, GPII should instruct the PSP to change the "Magnifier Enabled" setting to become "On".
There may be other applications for which similar situations may arise but I am not familiar with all of them so please double check.
Besides the above, in most cases we have so far enabled the actual value of the enabled terms - so having a "MagnifierEnabled" value of false would have no effect on whether it's launched.
We will reintroduce a decision that we made a long time ago, but never actually implemented, namely the "dynamic" or "requiresRestart" key of a solutions registry entry denoting whether a solution requires it's update directive to be wrapped in a "stop"/"start" cycle or not. As pointed out by Antranig Basman this is also a requirement for the PSP to be able to render different icons depending on whether solutions need a restart (https://docs.google.com/document/d/1a7uNCSR0dTqOulTwNIBxvS_qZQJpJGLrG6qokE6Vol4/edit#heading=h.gcdhfuh2ni2x).
Having this flag for a solutions will allow us more fine grained control when a setting change and we (still) dont want the solution running afterwards, etc. The dynamic/requiresRestart should be settingshandler block specific (i.e. not related to the type of settingshandler, but to each of the potentially multiple blocks of a solutions registry entry)
In terms of the *Enabled terms, a reasonable solution is to have an entry in the solutions registry specifying which common term dictates it's launch state. For example, the magnifier would have: "enabled": "http://registry.gpii.net/common/magnifierEnabled". This would allow us to treat these preferences as any ol' common term/preference with inference, etc., but know that it has a special meaning when necessary, e.g. in the matchmaking process, etc.