Well, like I said, in WUFFS this literally can't happen, WUFFS doesn't have any concept of runtime bounds checking, likewise it has no runtime overflow/underflow checking, if the compiler can't see why what you're doing will obey the constraints you don't have a valid WUFFS program at all (well, library, WUFFS is a special-purpose language so you're not going to go around writing whole programs in WUFFS)

And it's still a pretty sad indictment when a compiler is looking at your access, can see it's outside the boundaries and doesn't reject the program because the language (e.g. C) wasn't defined with this obvious expectation.

For me it's in the same category as the (now fixed in an errata) behaviour where as I understand it C++ 20 std::format didn't consider it a compile time error if you wrote

  format("check X: {} Y: {} and Z: {}", x, z)

... even though that's obviously an error, and it's obvious you can detect it at compile time, the original specification said nah, this code just blows up at runtime, good luck with that.

How would you write random app X? That is my point, I don't care about special niche cases.

I think a lot of people would already consider the cases you've declared to be relevant - where dying due to bounds failure is unacceptable - to be niche cases which need to do their own work to stabilise and not act like this is everybody else's problem. It isn't, for example, as if explicitly checking bounds isn't possible in Rust if you want to do something other than give up.

For example I would consider it acceptable if feeding badly corrupted MP3s to the MP3-capable CD-radio makes it stop working... until I disconnect the power and restart it. Nobody dies, if it's very annoying I should remove the offending MP3 file. Whereas if it causes random mayhem that's a problem because now troubleshooting is impractical and most likely the apparent solution is to replace the entire device.

And remember that such "turn it off and on again" is considered acceptable even in some systems you probably deem safety critical, so long as it needn't happen when actively dangerous. For some years trains in the UK with a beacon-based safety system couldn't handle waking up next to a beacon, their firmware wanted to start by not seeing a beacon, then encounter beacons while travelling - so waking up next to one was confusing and they'd go into an error state. The fix? Mostly "don't park the train there when it's to be switched off", but when it happened inadvertently, they would move the train a few metres with its safety systems disabled, turn the power off, wait a few seconds, turn the power back on and no longer able to see a beacon it was now happy.

That is where I disagree, when you buy a pair of shoes that are somehow uncomfortable to wear, do you live with the pain or go to the shop to exchange them?

Exactly that is what we are missing in the software industry, the niche cases of high integrity computing should be a common practice, just like most people usually don't put up with broken stuff when given the option.

We need more liability not less.

When I buy new boots they're uncomfortable for at least a week or two. Replacing the boots wouldn't help at all, the boots adapt to your feet and your feet adapt to the boots, I don't have money to get tailor-made boots that would fit to the millimetre on day one if that's even a thing -- which I suspect in fact it is not (that is, people who could afford such boots don't actually spend hours every day walking and so probably wear shoes which are comfortable but less effective).

User experience matters, and actually just dropping dead in error cases makes for a better user model than many outcomes. The user has a model of what the machine does, which is always over-simplified and often plain wrong, but it's vital to try to get to a place where the user's model doesn't contradict how it's actually to be used. Undefined Behaviour is the enemy of this outcome. The user definitely does not have a correct model of what Undefined Behaviour will be, as we see many programmers don't either, whereas "If I do this particular dumb thing, it stops working and I need to unplug it and start over" fits in the user model relatively well.

Computers aren't special in this regard, watch "Sully" (Miracle on the Hudson), the cockpit dialog is roughly correct. What does their QRH tell them to do in the event of dual engine failure? Turn the engines off first and then try turning them back on again. Didn't work because their engines were trashed, but if even one engine had restarted, those QRH instructions mean there would be no film, just a scary incident some passengers tell stories about and an aviation safety file somewhere, the plane climbs (slowly) on one engine, they're still an emergency but they can put it back down on a runway at their leisure.

Some people miracously avoid death by not wearing a seat belt, yet the statistics prove wearing it is still a much better option.