...

Thanks for the significant engagement. The godbolt examples, the implementation notes on GCC and Clang, and the close reading of P4363 are very helpful especially for the wider audience.

One sentence in your reply needs a correction:

In a way, profiles *is* compile-time proving that a given guarantee holds, not actually too dissimilar in spirit from compile-time proving contracts, just with a wider scope.

Profiles are not the compile-time half of an arrangement in which contracts keep the runtime. P4317 specifies the intended model: a profile owns the guarantee, the enumeration of what is checked, and the response when a check fails. Some of that response happens at compile time, some at runtime, and the profile decides which. P4324 (Section 4) specifies contracts and profiles as independent peers.

The summary "contracts do the runtime machinery, profiles do the compile-time proving" reads as agreement, but it answers an open question before the question is polled. Who owns the response to a violation of a core-language rule is contested. P4297 asks it directly and argues it should be polled by name; P4306 compares the two configuration models.

The same applies to the remark that postponing contracts would cause issues for "anything else that tries to rely on their specification for runtime checks and failure handling." Which features are those? Profiles as specified do not rely on the contracts machinery for their response. That independence is the point of the design.

Your demonstration that P2900 can mimic compile-time checking by leaving the violation handler undefined came with your own assessment: fragile, and not usable in general. I agree. The compile-time checking story for contracts is not settled, and proposals like Jonathan's should be evaluated on their merits rather than treated as already covered. And in your review of P4363 you observed that the current modes include "two of which guarantee not continuing into the code whose preconditions was broken." That is the property the safety discussion keeps returning to: the response that matters does not continue into a state the language does not define.

Since the point surfaced several times in the thread: nobody here argues against the violation handler being invoked, or against logging. Where the state after a violation is still defined, as with library-level checks such as Bloomberg's bsls_review, log-and-continue is good. What some of us contest is narrower: continuing past a violation of a core-language rule, into a state the language does not define, as the default and portable response.

Thanks again for engaging on the substance. I would urge everyone to keep these two questions separate going forward: who owns the response to undefined behavior, and what the response should be.