This will always be an issue when dealing with a language as entrenched as C: Most of your user-base will have oodles of code written under the previous standard. If you break backwards-compatibility on a level that's going to take them multiple man-months just to get working again, most aren't going to bother and will stay with the older standard instead. Your new standard stagnates and dies.
There IS a way to do this, but it's not nearly as simple as you seem to believe. Take a look at what's happening with Python 2 & 3. It's a difficult, albeit possible, transition, and I'm not sure how often exactly one can reasonably expect to pull it off.
I agree that old code is sacred and I agree that handling backward compatibility is not an easy task, but carrying decades old baggage isn't a solution either, if you ask me. I remember how one day while I was coding in C++ and I realized how much baggage I was carrying in my mind at each step while writing code.
Of course programmers will not switch to the new standard if it does not provide enough advantages, but then history shows that people are willing to even switch languages if their current one becomes an unmanageable mess.
As PG said in an essay of his, different versions of a language are different languages. Then just treat them as such.
Nowadays we shouldn't be dealing with pitfalls and complexities which resulted from thirty years old design decisions. New versions of a language should reduce complexity of a language instead of increasing it (for the same semantics).
I'm very happy of having left my job as a C++ programmer: I don't have to deal anymore with such madness. And I'd bet that many members of C++ committee are Ph.D. and beyond, showing once more that the more you study, the more you are in danger of losing contact with reality and practicality.