> No it doesn't. On none of the three major compilers does the code you've
posted compile. Seen here: https://gcc.godbolt.org/z/EEeMae
Wrong. It does, indeed. See here (MSVC 19.24): https://godbolt.org/z/9Tb313
What you have to do is to enable C++20 support by using `/std:c++latest`
compiler flag (which you did not).
I don't know about other compilers besides MSVC and ECCP, which both work
fine on all examples I've sent.
Note that MSVC does not support `requires requires` yet, but I've not used
that syntax anywhere.
You can see a list of compiler support here:
https://en.cppreference.com/w/cpp/compiler_support
Very nice site, I do recommend using it even if not all data is accurate,
up to date or even valid.

> Um, no it doesn't. Constraints of any kind do not require parsing the definition
of the construct being constrained. Constraints are only based on the
declaration. You cannot constrain a class template `T` on the properties of
`T` itself.
Wrong. See here: https://godbolt.org/z/Pjjrsd
Compilation success, Compiled program runs and returns 0 as X exists.
[Note: `__if_exists` is a non-standard statement that works i.a. in MSVC,
ECCP, and clang. — end note]
[Note: While X exists, it's neither constructed, specialized nor
initialized. — end note]
Modern compilers may have to do many passes in order to compile. And this
is a fact you should acknowledge.
A good place to start is to see this SO topic:
https://stackoverflow.com/questions/243383/why-cant-c-be-parsed-with-a-lr1-parser
Accepted answer links to a PhD thesis stating that "C++ grammar is
ambiguous, context-dependent and potentially requires infinite lookahead to
resolve some ambiguities".

Besides the godbolt topic, it looks like you don't want a conditional
`final`, because you don't want a `final` at all. And I do strongly
disagree with you on this point.
Encapsulation reduces errors by inheriting from wrong, unsupported or
simply outdated classes. Conditional final could be a big step into
reducing hard to detect and deal with errors with invalid inheritance.

> By "design tradeoffs," we mean […]
Thank you for explaining it. I've missed that in "How To Submit a Proposal"
article: https://isocpp.org/std/submit-a-proposal

> ..and why is that important to be able to do? If I can't construct a base
class, that seems to prevent using it as a base class sufficiently well.
Disallowing constructing a class does not disallow inheriting from it, same
as disallowing initializing a class does not disallow inheriting from it.

- - - - - - - - - -

At this point I do see that my proposal, beside all other concerns, seems
not to be as good to you as it is in my opinion and I see there are no real
changes to get this proposal numbered and voted.
I'd like to thank you again for your responses and I think I'll either give
up or eventually try again with better motivation and when reflects will be
well known, so in about 9 or 12 years (optimistically).

I wish you a great day.