It was. And no, breaking change is not what you seem to imply it is. When talking about breaking changes, introducing new keywords is not what people usually think of. It's irrelevant.

Sigh. "Irrelevant" except in the sense that the code used to build and now it doesn't after a gcc upgrade, you mean. This is an attitude shared (c.f. "greenfield" comments elsewhere in this tree) among a bunch of people who do intensive development and maintenance on active products all the time.

That use case is probably less than 20% of all the C++ development cycles out there. This is a 40 year old language that the bulk of the industry has decided to abandon for new work. The large majority of people doing work on this code are doing minimal-change updates, and nonsense like this is how you end up with rules like "We have to deploy on Ubuntu 20.04 still because the AbandonWare 4.7 library doesn't work on later version".

And it's avoidable, but not if you run around lying to people and yourself about what a breaking change is. Again, look at how C does this. The C standard writers actually know that they're updating a legacy environment and care deeply about full backwards compatibility.

Nonsense. Adding more keywords to a language is avoidable? Or making the compiler stricter in checking the integral promotions is avoidable? Sure, it is, but only if you stick compiling all of your code with C89. You're barking at the wrong door.

Adding keywords can be done compatibly. Again, I'm not making things up. A C18 compiler can absolutely build K&R C programs that are probably older than your parents. (C23 did roll back some stuff, to much gnashing of teeth, and seems unlikely to become a default mode for that reason. Most projects are holding at C99/C11.)