I disagree that this would be a "breaking" change as many people have already resorted to using extra () and such a change might actually may "fix" broken code which makes the reasonable assumption that things like == have a higher-order.
If you're using parentheses, as has been recommended for decades, there is no problem. Otherwise, it is likely that such a change would adversely impact previously working code. There just isn't a pressing need to change it.
Besides the fact that its unintuitive and could lead to low-level or hard-to-find bugs?
It seems to me that C would benefit greatly to iron over its many inconsistencies and exactly the kind of thing people expect in new revisions of the language.
Also, I dont see how it would impact previous working code when compilers already do things like allow selections between versions of languages a la C99, C2x, etc. Users could just avoid the new version if they don't feel like changing.
I don't think most users of C want things changing underfoot.
Keeping track of all the version combinations is infeasible, especially when you consider that an app and its library packages are likely to have been developed and tested for a variety of environments. To the extent that existing correct code has to be scanned and revised when a new compiler release comes out, one of the primary goals of standardization has failed.
I disagree with your view of standardization - as restricting changes to be additions to the runtime seems pointless as users could easily use other (often more optimized) libraries.
But, I do see the benefit of having a language "frozen in time" which never really changes and can be mastered painlessly without having to refresh on new versions. Perhaps C is special/sacred in this regard.
https://ericlippert.com/2020/02/27/hundred-year-mistakes/
int x = 0, y = 1, z = 0;
int r = (x & y) == z; // 1
int s = x & (y == z); // 0
int t = x & y == z; // 0 UGH