This reminds me of Peter Drucker, "What gets measured gets improved". Conversely, if you don't measure it, it usually doesn't get improved.

Its a tough situation to be in, especially when RISC orthodoxy elevates measurements to a paramount position in the ISA design process. I don't think they were wrong to do so, either. The error was in finalizing the ISA without more backends to work with.

How much business code out there burns most of its cycles in Java/C#/Rust/Go? Having even one of those (lets face it: Java) would have gone a very long way. How much client computing spends most of its cycles in (JITted) javascript?

I understand the tradeoff that drives this omission, though. How many VC megabucks (Tens? Hundreds?) would they have had to spend commercially on a bet? Alternatively, how many grad student-years grinding through low payoff work to prove yea/nea on the value of checked arithmetic?

Lets say that you make a hip-shot bet on some checked arithmetic support without the supporting toolchains and application code to back up the design choice. You could end up making a different set of mistakes instead and end up in the same situation.

I think the only mistake was in finalizing the ISA without any support for checked arithmetic. My belief is that doing it well will not be orthogonal to the rest of the ISA's design, and therefore is a poor candidate for an extension.

C really did screw things up by just refusing to address overflow in any form, didn't it

I don't think C screwed up. C's objective was to standardize a set of practices based on what the hardware of the day was capable of. If they had pessimized performance on one architecture because it failed to provide efficient checked overflow (or any other feature), then C would have never made it to standardization.

ISO C is therefore a three-way compromise between three communities: Software authors, compiler authors, and CPU manufacturers. You will naturally end up with some decisions that dissatisfy some members of each.

Better would be to say that the C standard committee screwed things up by refusing to address a lot of issues over the last 35 years.

Not really, they have addresses pretty much all of the issues. Now, you can argue that they favored compiler authors when doing so, but they have consider the problems and done things in response to them.

Yes. In many ways:

1) it’s pretty important to have easy syntax for math with overflow checks. Otherwise there will be bugs. Bad bugs. We have those and it sucks.

2) it’s pretty important that if the overflow wraps in ISA then it wraps in language semantics but C just says “meh whatever” for signed overflow. That leads to even more bugs.

The HP3000 had "SPL" - Systems Programming Language -- as its way of doing what C does. It had a specific syntax for checking the error codes: if <> then <whatever> so whatever previous arithmetic did, you could check the machine's flags directly. Can't do that in C. https://en.wikipedia.org/wiki/Systems_Programming_Language

At the time C was designed not all machines did represent signed integers in 2 complement. Therefore it was not possible to define behavior for signed overflow. They probably should change that 2020^^

GCC has intrinsics for integer math with overflow checks

C++ formalized two's complement already. Formalizing power-of-two word size and 8-bit bytes might come.

That’s my suspicion too!

I don’t think these folks have seen what modern languages do.