You seem to have a vastly different experience with what the impact of IFNDR is in practice.
In the case of odr violations, it is certainly not my experience that "your tools will diagnose this because it is bad", it is "your tools will never diagnose this and if you mess up ensuring you don't have odr violations in any way then the resulting bugs will be very costly to fix". GCC"s approach to IPO makes it clear that compilers are even actively pushing to make previously "benign" odr violations when using assertions into sources of UB. That is bad, and something a language feature must fix -- C++26 Contracts do.
C++26 Contracts *also* let vendors provide you an option that says "don't let me link TUs when the TUs have different contract configurations" or even better options like "warn me if i link builds where the same function has been built with different contract configurations". Build configurations are outside the standard, and platforms are completely free to define when they do and don't work together, and to provide support for enforcing that rule. Nothing in C++26 Contracts prohibits this possibility.
Now there is one world where odr violations are detectable reliably, and that is a world where you deploy very expensive odr checkers that fully understand the leeway allowed in produced binaries within the flexibility of the odr. Such checkers have no knowledge of assertion macros, and are thus anyone actually using defensive checking at scale must make a choice between having any checks in their code and employing such checkers. My experience and that conveyed to me by people at many other companies as that this is a tradeoff where assertion macros always win, partly do to the intractible cost of the odr checkers at scale and partly because contracts are too useful in practice.
Contracts being a language feature gives the odr checkers a target for what they must understand when comparing compiled functions and deciding if they are odr violations or not --- which is why we say that C++26 Contracts enable such tools to exist.
So C++26 Contracts have taken nothing away except the case where you make normal use of defensive checks the same way you do today and as a reward the compiler gives you gibberish because it can say your program is ill-formed. The *only* negative possibility is that you thought you (the person building the program) had built a function one way but it turns out that you (the person building the program) also built it a different way in a different TU and so you get the semantic from that TU. That's exactly what we can get with linker technology today, and in the future we can both educate people better about making bad assumptions that they are in control of things they are not in control of and we can provide more options (in tooling, outside the standard, and all fully conforming with C++26 Contracts) to give them the controls they want.
As others have said, what C++26 Contracts do not do is require that mixed mode be supported in any way shape or form. We give implementations the freedom to provide that ability, because it is abundantly clear to some of us that not doing so will prevent any adoption of the feature. We also give them the freedom to improve the ecosystem and toolchain to better serve their own users.
So now I will rephrase this as I believe Mr. Voutilainen would: It frankly astonishes me that anyone is arguing that IFNDR is a better situation than what we provide with C++26 Contracts, because IFNDR predominantly results in incredibly costly and challenging runtime failures, not friendly compile-time errors or reasonable behavior.