In the days when XML was popular I've been more active in several Web forums that helped novice users with particular technology (and that included XML). Not a single confusion about XML namespaces came from someone who read the reference. Quoting the reference would be also a very efficient way to clear the confusion.

Bottom line: it's not a problem worth mentioning. In the grand scheme of things an hour you'd have to spend reading the specification is a drop in a bucket compared to all the time you'd have to work with XML. It's a fixed-size effort that you have make once. Compare this to having to deal with bad "number" serialization that you have to deal in JSON every time in a new program that deals with JSON.

Two reasons:

1) Because it's unnecessary complexity. When you add unnecessary complexity into fundamental technology that everything uses, you've now made everything worse. It's like polluting the lake, and then ignoring the fact that beginners need to learn how to boil the water properly drinking it.

2) Because that prevents the technology from being adopted. Whether you think it's justified or not, beginners will choose the tech that's easier to use, and it will succeed.

The market of technology adoption forces us to make things simple for beginners, and in the end, that's good for all of us.

Even without namespaces, it's trivial to handle { "NamespaceA": {....}, "NamespaceB": {....}, }

There is seldom need to mix it in the same object, and if you need that, you should think long and hard if you are on the right track.

As for multiple ones in the same object it makes sense if you want to reuse a definition used elsewhere e.g. to add an address using a predefined address type. It is like using structures/records in programming languages but with no pointers for composition.

Or spend 0 hours reading the JSON reference to reach the same result.