Right, but those examples still compile, they just invoke UB. Normally you want to avoid that, but sometimes you actually do want to, and the fact that the result is UB gives the compiler the freedom to support additional semantics.

For something closer to the original topic, consider:

    static const double x = 1.0/0.0;

That's UB, but the compiler is free to declare that it follows IEEE-754 and fully support this. The equivalent with constexpr doesn't allow that same freedom, and the compiler must consider 1.0/0.0 to not be a constexpr.

Ah, I see what you mean. A few years of warnings-as-errors mode made me forget that the most bizarre constant expressions (not constexprs) will compile even if their results or what you do with them are complete nonsense.

I'd argue that the constexpr behavior is an improvement, in that it enables errors for large swaths of obviously buggy expressions without breaking backward compatibility. If the committee wants to remove float-division-by-0 from the set of UB expressions, they should do that independently of the rules for constexprs/constant expressions (as some Googling gives me the impression the C standard did with Annex F).

Generally, I think compiler vendors should not be distinguishing themselves by "reliably" implementing some "defined" behavior for what the standard declares to be UB[1]. At that point you're effectively implementing a proprietary language extension. "Implementation-defined" parts of the standard—and tooling/libraries, of course—are where vendors should be differentiating.

[1] I had a very traumatic experience with HP-UX and its configurable null-pointer-dereference semantics that may be biasing me here.