That's not what C1X is for. It's a straightforward evolution of ISO C99 which adds features without breaking anything. If you want a similar low level language which is not compatible with legacy C you don't have to look far: history is littered with their carcasses.
Think about C++: not only legacy C++ was broken by each standard, it was also broken by each compiler releases. The change of compiler release was always a journey.<br>
It is normal that introduction of a new keyword breaks legacy C. A new standard is compatible with legacy code if the only adaptation required is to rename identifiers that collides with new keywords. There is no excuse for producing such a crap.
The issue always confuses me. The committee puts in a lot of effort to avoid introducing new keywords or repurposing obsolete keywords. This introduces some horribly overloaded keywords and awful syntax. Of course, new keywords break old code but what is so difficult about a grep-replace on your code base? The only reason I can come up with are the few corner cases where turning an identifier into a keyword can produce well-formed code with a different meaning but I have a hard time imagining such a thing. Can someone shed some light on this?
Pain now, or pain later? Most choose to put off the pain.
Python 3 chose pain now - and I think they made the correct choice - but three years later, people are still upset and many, many Python libraries have not made the transition.
To be fair, though, the Python core team envisioned a five-year transition plan and we are starting to see major frameworks make the switch. Django, for example, recently announced full Python 3 compatibility in their nightly builds.
I agree that's fair, hence why I think it's the right choice even given the pain. The reason I pointed out that it's been three years is that sometimes, it's not just a choice about pain now, but a prolonged pain starting now and maybe lasting years.
