Also, I don't think that having this feature would have made contracts less necessary. None of the current contract evaluation semantics do what OP is asking for. However, it would be possible to add a fifth "proof" contract evaluation semantic, one step up from ignore. That makes it seem to me like what OP proposes provides additional motivation for contracts in their current state, since our C++26 design could be extended to provide everything OP is asking for.

Now thinking about, making compile_assert a use of contract_assert with "proof" contract evaluation semantics also solves the issue of optimization levels.

The user can control what contract evaluation semantic is chosen using build flags, just like optimization levels. To prevent unusable debug builds, the user could simply use ignore or enforce semantic on debug builds (with -O0) and "proof" semantic on optimized builds (-O3) instead of ignore. If the feature is tied to contract semantics, we don't need to introduce a notion of optimization levels into the standard.

Not to pat myself on the back too much, but I think this is brilliant.