Lénárd, that is very far from meeting in the middle. I think it saves
you having to specify template argument deduction, lets you use it as
an underlying enum type and bit-field, and that's about it. Since it's
a core type, you still need to specify the implicit conversions and
other aspects to behave exactly like in C.

I don't think those C semantics are good for C++ anyway. Why should
std::bit_int<32> + int result in int? It makes vague sense in C, but
that is completely surprising for anyone who expects it to behave
vaguely like a std::bit_int<32> class template (like the spelling
suggests). This spelling would still require a compatibility macro
_BitUint(32) to expand to unsigned _BitInt(32) or std::bit_uint<32> in
C and C++ respectively.

Also, the appeal of making it a class type is that the implementation
effort is tremendously lower. You can implement it as a _BitInt
wrapper type and get a really good and easy library implementation
that way, but you don't have to. We are not forcing every C++ compiler
on every architecture to have N-bit fundamental types. If Microsoft
doesn't want to support that (yet, or ever), they can just do it as a
pure library implementation and later switch to a fully-fledged one.

We can actually mandate that the implementation supports widths of at
least 16777216 or something (on freestanding), which makes this
feature useful and portable for C++ developers. A pure _BitInt
fundamental type only mandates 64; that is what C mandates.

To be fair, you could perhaps make it unspecified whether it's a class
type, and, WITH EXTREME CAUTION ensure that all the semantics you
specify about _BitInt are actually implementable as a class type.
However, even in the best case, you now have standard conversions when
std::bit_int is fundamental in one impl, and user-defined conversions
in another, making overload resolution give you different results
between implementations. This fundamental/class type split seems like
an implementation divergence minefield that users will have to suffer
from.

Last but not least, you can specify all the semantics, all the
conversion, all the operators as functions in the standard library.
This makes it much easier for new users to understand these semantics.

In summary, I think you introduce a huge set of problems by making it
a pure fundamental type (or conditionally one). If C didn't have it as
a fundamental type, that suggestion would be pretty much unthinkable,
and that is how we should look at it. What is the design that makes
sense in C++?