Fail fast is a great philosophy for end-user software. But it is not that strictly good for middleware, and is almost certainly wrong for a kernel.

Crashing the whole kernel at the drop of a hat seems like a pretty extreme stance to take as a general policy IMHO. Killing and restarting the driver will usually suffice, although some data may be lost and have to be retransmitted.

you should panic in a production environment and reset the state of the machine (which has become indeterminate).

The correctness and validity of the data >> uptime.

If the remote end is going to ignore that data anyways, would it really be such a bad idea to keep running? Do you really want to go down in order to ensure that a remote who's ignoring your data can get correct data to ignore?

Of course you never know what sort of effect the corrupt data is going to have, so it's always hard to make that decision.

Like that issue with libraries linking against objective-c frameworks that has crept up with High Sierra and broke most of the Ruby world: Yes. The usage was incorrect. Yes, forking after threads are launched leads to undefined behavior, yes, knowing about it is a good thing.

But: So far the crashes have been rare in the common use-cases (or they would have been fixed), so High Sierra's change to blow up loudly when it detects the misuse has actually caused a lot of trouble for people where things worked fine before.

To the point where many Ruby developers were complaining about High Sierra "breaking" their workflow and recommending against upgrading.

The new check is totally justified though. The existing forking behavior was wrong and it could have lead to crashes down the line. It didn't though. And now people are forced to fix something that was never an issue to begin with.

It's a fine line to walk and while I generally prefer things to blow up as they go wrong, sometimes I catch myself wishing for stuff to just continuing to work.

On some self-reflection, I come to the conclusion that I want my cake and eat it too.

Systems that matter, are.

The kernel (for my intended usage) should intentionally panic only if there is a risk of corrupting my .tex files.

Potential data corruption is far worse, so is a potential security compromise.

E.g. performing industrial control automation or airplane rudder control in a completely segregated network.

You want control over these tradeoffs, not hardcoded behaviors.

Look at seL4, minix3, eChronos instead.