It's a warning not an error. Moreover, it is very hard to come up with a legitimate usecase of 2^32 as an expression. People who use it to set bit flags will use &, and for bit flags, octal or hex notation is probably better.
Mostly written as y ^ (1 << x), which could easily resolve to these expressions. Mostly at runtime, sure, but there are exceptions. Especially if you like descriptive constants. I would expect it to be quite difficult to separate the "correct cases" without people starting to just suppress compiler warnings or trick it with writing the same stuff in different words (which might be better).
On the other hand, setting max_short to something like 18 is probably a really god prank in larger programming environments. The compiler would just ruin all the fun here.
We’re talking about a parse-time check; things that resolve to those values after identifier binding won’t throw the warning. It’s not a warning about what you wrote (semantically), it’s a warning about how you wrote it (syntactically).
Things that resolve to this don't trigger the warning, and it is a compile time warning.
And then specifically looking at 2^X and 10^X occurring in source code.
You're suggesting that using the C language as specified and intended should produce a warning... That makes no sense.
As for limiting the base, that is a more fluid matter. I guess you want to avoid warnings for very large numbers. Because those are more likely legitimate.
Many build environments are set to treat all warnings as errors.
The point is that 2^32 is a perfectly compliant C expression that is neither misleading nor ambiguous, and that also won't create any variable overflow. It uses ^ exactly as intended. Why should the compiler complain? Why should I get a warning/error when following the spec to the letter?
A new type of misleading and error-prone statement has been found, so it seems entirely reasonable that this is added to that list.
This seems to be the entire intent of compiler warnings (these days anyway)