There is a certain view, one that is easy for people to fall into, to the effect that while backwards compatibility in new versions of languages is important and should be given due weight, sometimes the language designers can, do, and should decide that the change is important enough so that it should be made. Let us call this the language designer view of language changes.

The problem for this view and for the decisions that come from it is simple:

Programmers do not have to accept what you give them.

The view that language authors can ignore backwards compatibility as inconvenient or not important enough and force people to accept incompatible language changes ignores this fundamental reality. Programmers are not passive objects that have to accept whatever changes you make; if you push them too far, they will revolt and ignore your new version of the language in one way or another. And revolts do happen; look at what happened with PHP4 versus PHP5.

(I'm sure that the causes were complex, but the ultimate upshot is that PHP5 experienced what could politely be called a 'slow uptake'.)

So the real question a language designer faces is not whether their changes are necessary or important enough to justify breaking backwards compatibility (although they should be); it is whether the changes are drastic enough to provoke significant user revolt. If the changes will provoke too much user revolt it doesn't really matter how important they are, because on a practical level they're impossible (you can change your version of the language, but not the version that programmers actually use).

Or in other words: significant language changes are at least as much a social problem as they are a technical one, and language designers need to deal with them as such.

(This is sort of amplifying on something I wrote in passing in PracticalLanguageGuarantees.)