Assuming that this or something substantially identical does land for C++ 26 I think we should start betting on when SG23 (the committee's Study Group for "Safety and Security") is replaced by some hypothetical SG24 "Safety and Security No But Really".
We already know that because C++ Undefined Behaviour can cause what are called "Time Travel" defects and this paper doesn't do anything to prevent it, adding contracts in C++ can make your software less safe and induce more surprise behaviour. We also already know that C++ programmers tend to write erroneous UB tests when trying to grapple with edge cases that might induce Undefined Behaviour, setting off the very calamity they fear. So this new feature, rather than being (as its proponents claim) a way to improve the safety of C++ software, or neutrally becoming a dead letter as the UB "passes" contracts that in fact are not met, might instead become another footgun for the language.
A functioning SG23 should have caused this proposal to stall out until it can explain how it will prevent this problem, rather than merely re-stating the problem (in 3.6.4) and saying well that's unfortunate but maybe somebody else will fix it. That stance might be extremely unpopular with some C++ programmers, who believe they don't make mistakes, but as it stands this work will instead cause all the people who do make mistakes (which is in practice everybody) to regret using contracts. If SG23 isn't interested in preventing C++ from becoming even more unsafe, what's the point in the group existing?