Normative: specify settings commands

[jugglinmike]

Prior to this commit, the behavior of all three commands in the ":settings" module was entirely implementation-defined. Although it is known that today's implementations require some leeway in their support of this behavior, the high degree of ambiguity obfuscated even the failure modes. This would leave clients and implementations guessing about when and how errors might be reported. Additionally, the prose did not communicate the rationale for the ambiguity.

Specify the desired behavior while leaving implementations the flexibility they are currently understood to require. Document the rationale for this flexibility, including the editorial expectation regarding its eventual removal.

---

Preview | Diff

[jugglinmike]

@jscholes We were discussing the ambiguity of these commands during the 2022-12-05 Community Group meeting when our time ran out. We spoke just enough for me to learn a bit about the current needs of the NVDA implementation. What I've tried to do here is define the desired behavior while still leaving enough space for the kind of restriction you described.

As I tried to explain in the commit message, I think this better-suits both our short-term and medium-term needs. That is: it clarifies our expectations for today's implementations (avoiding the pitfalls of "spec fiction") while signaling our intent for an ideal future. Or, to lift a metaphor from @s3ththompson, it's a way to skate to where the puck will be.

[jugglinmike]

Formalising these algorithms is helpful in ensuring consistent implementation together with clear success and failure scenarios. Very nice work.

Thank you very much, @jkva!

When we merged gh-41, we introduced a conflict with this patch. It was limited to a directive for Bikeshed and was therefore straightforward to resolve. Because the resolution did not reflect normative change, I'm going to merge this without another round of review.