As I said in "what do version #s identify?", I said one big problem with version #s is how does the consumer know what to do with a version # it doesn't understand.
The obvious implication is that use of version #s requires some kind of mapping of the version # from an unknown version to a known version. I've talked a lot about how unknown content must be dealt with for forwards compatibility, but not much about the version #s.
This issue has come up in many different ways. An example is the attempted transition from XML 1.0 to XML 1.1. Each XML language has it's own, whether it uses namespace names or version #s.
An obvious solution is to provide some kind of algorithmic approach. The simplest approach would be to say that version #s will only have a "major" change if there is an incompatible change. For example, version 1.1 of a language is by definition compatible with version 1.0 and version 2.0 is incompatible. Then, when the producer puts 1.0, 1.1, or 2.0, a consumer at any level will know whether it can process the content. This also means that there is a choice about which version # to put in, the lowest or the highest.
A strawman approach is to say that the document should contain the lowest version major version and highest minor version that can be used to process the document.
A document that contains "1.1" means that any 1.X processor can process it, and it was produced by a 1.1 producer. A "2.0" document means that a 1.X processor cannot process it, but any "2.X" processor can.
Then the language MUST have wording about processing unknown version #s. Sample wording: "A processor of this version MUST not fault if it receives a document that contains the same major version number." Of course, the language must follow the "Must Ignore Unknowns" rule and ignore the "future" things it doesn't know about.
XML
Imagine XML had done this. XML 1.0 could have said ignore unknowns and require no faulting on XML 1.X XML declarations. Then if XML 1.1 that was backwards compatible with 1.0 then it would have worked with all XML 1.0 processors.
Namespaces
XML Namespaces are a much different beast because they are hierarchical and much more expressive than numbers. Going from "http://example.org/ns/foo" to "http://example.org/ns/fooversion11" is much harder to do the mapping. It would actually require that the Namespace URIs are NOT opaque. Something like: "Any Namespace URI that begins with http://example.org/ns/foo/1 MUST not cause a fault in processing".
Again, just mapping the content from a newer version to an older version is not enough, the version identifiers must be mappable as well.
Crunching version numbers in order to understand how to process a document is certainly simpler, but XML.com ran an article called "A Smoother Change to Version 2.0" which I think proposes a superior solution. It suggests letting documents themselves declare which versions of a standard they'll be compatible with. This way, a 2.0 document that is backwards compatible with 1.1 can still be processed by a 1.1 application, but a 1.1 application would choke on a 2.0 document that makes use of new and incompatible features.