This gets back to another one of the threads above.

The concern I have is for situations where a service might assume that a setting it has just set as an override will be honored but ultimately is not because the setting's value is changed out from underneath that service later on.  This probably wouldn't be the case for a single service making successive calls to override individual settings because that service would presumably have a holistic view of what it believes the current settings are at any point in its execution.  If we open this up for piecemeal setting of values, though, it seems more difficult to constrain it such that only one service could make use of it -- to avoid the conflict scenario mentioned above.  Another option would be to make the settings be one-shot only at a per setting level rather than for the whole block of settings.  The concern I'd have there is around unintended relationships between settings that might cause problems.

I think we can open this up for more granular setting or multiple shot settting later on if we need to but it seemed more appropriate to go with a constrained implementation initially and see if that would be good enough for the long haul.