The standard differentiates between "unspecified" behavior, which is as you describe, and "undefined" behavior, which may be completely nondeterministic at runtime.

And that's is the part that irks me a little. How should I expect anything when I don't expect the undefined behavior to begin with?

Say I manage to accidentally do something undefined, I do some math incorrectly on some index, and try to read out of bounds on an array that didn't implement bound guards. Now already it's my fault for several reasons, but in a complex project what the array is, and the details of the array may be "vague", especially if it's not something you did yourself in the project. So as a scenario, it's not completely out there. (some other dev knew the index was "always" right, and did premature optimization and used unguarded arrays instead) Still completely avoidable, but it can happen.

But if only an edge case actually leads to an out of bound read, the problem will probably never happen where the issue is. An experienced dev might never step into this mess, but sometimes this happens when other people change up what others did. I've had similar problems at my workplace, just not with undefined behavior as a result. At the end of the day, you sitting there with hard to know issues that have hard to know consequences.

This doesn't require a special programming language to solve, it just requires a guarded array first and foremost, tests and good reviews might see the bug as well before production. Which in C++ we were taught about from the beginning. If performance actual was a problem, then I guess we'd maybe still end up with this bug in the example. But my point is something along the lines of, all the good practice comes down to the choices of the individual developer. And the choices of one, also affects the next one.

If we could instead place those choices a step up in the chain however. Have the language enforce safety, unless you specifically say you need the be unsafe. So in my example, other the code would be safe already or someone threw and unsafe block to do their "fast" read of the array. In one case, I'll make a crash due to a bad read, the other I'll have to really evaluate why this is unsafe to begin with and apply extra caution. That extra caution goes away when everything is unsafe. Kinda like a small PR will have 15 comments, a huge PR will have less. You won't dedicate your all for every line of code, but if a line is tagged "unsafe" you sure as hell will.

Nothing is a magic solution to everything, and unsafe array reads are just a simple example of fucky behavior. I'm not sure if it still stands, but even something like this was/is undefined in C++

a[i] = i++;

That is to me something you quickly can forget about. And it happens because of compiler optimization that happens even if it breaks the code, because normally the index in the array should be a different variable. Again, here is something that should have obviously stopped me. If the compiler still follows through (I'm sure there warnings for it) then it's just letting me do an error no one should be allowed to. There is no reason this should ever compile.

If we cna do that for everything at the language level, it's a win in my book.

I think there's a much higher chance of running into UB on C++ vs C due to the complexity of the language. That's why I don't touch C++ and only use C if a higher level language isn't available. I can understand the C language in its entirety, whereas that's really not feasible with C++, especially at the edges.

So I think it's absolutely fair criticism of C++, but a little tired for C.