Hello,
in my view, there are two slightly different issues here: 1) experimenting with language changes, and 2) having a "modular language". We are using a single mechanism---`language` pragmas---to achieve both, which is where the tension lies. When language extensions are first born, they seem to be very much in use case 1) and I think we should allow ourselves to change them, improve them, and even remove them. I also find use case 2 quite useful: I sometimes think of GHC as implementing a family of languages, made out of modular blocks that all work well together, and `language` pragmas in a module document which language configuration is being used. I think that's very cool and makes GHC somewhat unique.
Given that we have to balance these two goals, my preference would be that we adopt option (3) where we do allow some changes to extensions, but be cautious if these might seriously conflict with options (1) and (2). So we'd have to exercise judgment on a case by case basis.
To be honest, I don't really like the idea of having versions for extensions---I'd rather simply have different names for them if that's what we'd like to do.
Here is another idea which might help with this problem somewhat (and I've wanted something like this for other reasons too): we could provide a mechanism for naming sets of language extensions. If we had such a mechanism, I'd be a lot keener on simply adding new extensions, rather than modifying old ones. This would allow us to specify various language standards succinctly---as simply a collection of language extensions, and it would also allow companies or projects to have their own sets of "approved" extensions. Finally, in GHC some extensions already behave a little like this, in that some extensions automatically enable others---it would be nice if one could look up these definitions somewhere, without having to look in the compiler's source code.
-Iavor