That's why I didn't bother with "the behavior of the program is unspecifed", because that really is just undefined behavior.
But yeah, actually listing allowed behaviors and stating that the actual behavior out of them is unspecified/implementation-defined is more practical.
One example is conversion to signed integer in C17:
> ...either the result is implementation-defined or an implementation-defined signal is raised.
For example bound checking, while fairly cheap for serial code, makes it very hard to vectorize code effectively. Then again so does IEEE FP math and that's why we have -ffast-math...
In the end, it is not impossible, it is just tradeoffs.
I'm generally on the opinion that there should be as little UB as possible, but probably this is better done by compilers that can push the limit of static and dynamic checking technology instead of the standard mandating it.
You're basically defining undefined behavior. The way to do this "properly" would be "the program is allowed to do x, y, z, or also trap"–there's really not much else you can do.