Between changes in the standard headers, changes in keywords (without provisions to disable them for files written to older standards) Changes in API and ABI, there is a huge clusterfuck of underdocumented shortcomings in C/C++ that are mostly there because of standard ego-stroking. Many of which have no excuse for having shown up in the past decade given that most of them manifest in open source software that could have been tested against in an automated fashion to ensure that new changes to the standard didn't break older code.
I agree, for C++. Whenever I have breakages after upgrades, it's almost always C++. Programs have to be recompiled, because they've imported and extended templates that they themselves weren't in charge of. Even if the APIs remain the same, there are still breakages.
For C, there are far fewer problems. Yes, someone might change an API, but the general consensus is to not do that, but provide new functions. New standards happen, but only affect the source, and not whether binaries continue to work, like can be the case for C++.
C++ works well where you can control or dictate the runtime system, so it matches the developer toolchain. That's great for embedded-like systems where you can change the entire OS with upgrades, or long term stable systems like RHEL, where versions stay put for 10 years with only bugfix backports. But when binaries break after an OS update, they're almost always C++ ones. From big companies too.