My other reaction was that this sounds scary:
> a token with no caveats restricts nothing. It’s a god-mode token. Don’t honor it.
I guess it's technically "fail closed" but seems kind of brittle
By the time I was done with that project, the document for partners and vendors (if anyone wanted to implement their own instead of using ours) was several times longer than the spec, what with all the extra MUST and MUST NOT situations. Which is not that hard when you're dealing with swiss cheese.
Document.findById and Element.findById being able to return different (non-null) results being the most egregious one I can remember.
JSON says "if your document does this, parser behavior is undefined". So you need to declare that the parser used should behave in particular ways.
Both are best solved a robust specification and supplemental test vectors. If you define meta rules (e.g. JSON parsers must either fail or return the last object property), you still retain the value you hoped for by using something like JSON or XML in the first place.
The fundamental screw-up with XML is that it was a textual markup format (e.g. HTML or word processor documents) that got usurped for cross platform data transfer. Among many other problems, that put pressure on its design to be unambiguous to generalized tools - which wasn't an initial design consideration.
So you had an awful lot of making people use document markup processing tools to serialize and parse data structures, schema and transform systems that tried to target both mindsets and did a bit of a poor job at each, and lots and lots of abstractions to try to make it so you only had to deal with the problem once.
Even JSON is a bit of a pain the farther away from late-bound or untyped scripting languages you get.