[jeffffff]

of course the standard allows implementations to "behave during translation or program execution in a documented manner characteristic of the environment" if you do something that is undefined behavior, implementations are literally allowed to do anything they want if you do something that is undefined behavior. the key point is that they are not required to do anything, so what's the point of adding more undefined behavior for this case?

[Kranar]

The subtle distinction is that when the standard specifies that behavior is undefined, it does not mean that an implementation is forbidden from providing well specified and documented semantics, and hence the statement I replied to "Undefined behavior is always undefined behavior" is false and furthermore a common misconception.

The point of adding more undefined behavior for this case, or any case in general, is to provide optimization opportunities that do not require introducing changes to the syntax (such as additional type checking or analysis). That way a C++ compiler is welcome to provide debugging support and various checks when a program is compiled in debug mode, and then eliminate those checks and make very strong assumptions about the program's runtime behavior when a program is compiled with optimizations enabled.

This is in contraposition to OPs claim that "There is no "debug mode" for undefined behavior.". There absolutely is a debug mode and it absolutely can catch undefined behavior, and UBSan is an excellent tool for doing precisely what OP claimed is not permissible in C++.