Procedure for evolution of language spec

Even though the specs are published some time ago it is desirable to have the ability to improve them and fix the bugs.

The question is how to change existing specs and propagate changes to tools and testing (in particular CTS) minimizing negative impact.

Summary of previous discussions:
- If changes affect the diagnostics i.e. some code would be rejected or accepted differently from the older specs. What should happen to CTS and how to dial with the drivers that are already shipped that will behave differently to the new drivers?
- Adding an extension for each modification in a language doesn't seem like a great language design choice.
- Changing language version for a group of features could be an option but (a) how to define the amount of changes that is enough (b) how long would it take to wait for a new version release.
- Clang extension is not portable and has some limitations i.e. ideally it shouldn't be big changes.

Some early observations:
- Clang has one language mode for each standard i.e. -std=c++11. It documents revision that it implements and deltas between releases however there is no formal procedure for this.
- TODO: Check the procedure with ISO.

Start by reviewing the prior discussion summarized in the issue, then compare Clang's language-mode approach with the ISO procedure the issue identifies as TODO. Done means documenting an agreed procedure for changing specs and propagating changes to tools and CTS while handling diagnostic compatibility.

Written by the indexing model from the issue text.