I understand we have something like this:
* true: on if possible, else off
* false: off (always possible)
Which one is the default?
It depends. Some properties have true by default. The others have false.
There is no way to reliably configure "on", i.e. fail if it's not
possible. I agree that's a problem.
This problem can be solved
using an existing mechanism, OnOffAuto, which differentiates the "auto"
state and explicit the "on" state.
I guess you're proposing something like this:
* auto: on if possible, else off
* on: on if possible, else error
* off: off (always possible)
Which one is the default?
I converted on to auto and off to false in a following patch.
However, converting bool to OnOffAuto surfaces another problem: they
disagree how "on" and "off" should be written. Please note that the
disagreement already exists and so it is nice to solve anyway.
Yes, converting bool to OnOffAuto is an incompatible change.
Not just about conversion, but this inconsistency require users to know
whether a property is bool or OnOffAuto and change how the values are
written in JSON accordingly. This somewhat hurts usability.
This patch tries to solve it by tolerating bool values for OnOffAuto. As
you pointed out, this approach has a downside: it makes OnOffAuto more
complicated by having multiple ways to express the same thing.
It also affects existing uses of OnOffAuto, where such a change is
unnecessary and undesirable.