I would be careful about making std::bit_int a library type. A driving
reason for this to exist in C is to start using this fairly aggressively in
bitfields, and many vendors embedded and not have made it clear they want
to do this as an extension and improve the story for bit-fields in this
around C. Insofar as I understand it, having std::bit_int as a class
template would make it very, very difficult to coordinate in this fashion
without some interesting language surgery to allow this type, specifically,
in bit-fields. (Imagine similar to the wonky compiler internals to,
specifically, bless std::byte, but much more thorny.)

     One serious additional benefit of not making this a library-driven
feature as well is that a compiler is allowed to step on the "padding bits"
of a C _BitInt; a std::bit_int that has to fill the padding bits with
unused bytes can't reasonably be understood by a normal compiler as having
those unused bits in class members contain irrelevant padding values, and
so any clever size optimizations go into the trash without compiler special
casing or new techniques to mark parts of a structure as containing padding
bits.

     In short: please consider putting this into the language. While the
functionality can be approximated as a library type, you may run into many
thorny niche-but-nonetheless-important problems if such information is not
encoded directly into the compiler.

Sincerely,
JeanHeyd