I only see one good reason to introduce an additional alias: fixing some of the drawbacks of current behavior, i.e. automatic narrowing (and maybe widening) of integers. One minor reason would be that typing the underscore in int32_t is a little bit cumbersome on a QWERTY keyboard layout.

Is _BitInt solving automatic narrowing or just integer promotion?

Probably, automatic narrowing could also be fixed by profiles. Then, this point is moot.

In any case, if we were to introduce a new shorthand “keyword” for these special integer types those would need to be in a global scope and not hidden in a namespace. I believe that the OP’s research has already shown we shouldn’t name them u8, and so on. We could use the suffix _t, but it would be really ridiculous (when we already have uint8_t). To address my minor point about typing the underscore we could name them u8t. This might have a better chance of avoiding global name clashes. Or maybe u<8>. It makes it clear that it is a type (because of the template parameter). But, it would also be cumbersome to type having to alternate using shift for every single keystroke.

I see less of a problem with u8 having to know it is a type. People will get used to it quickly if it is standardized. (And most people also have highlighting in an IDE to tell them it is a type.) There is precedent that C++ uses unusual naming to avoid name clashes (like nullptr, co_yield). So, we could use u8t instead.

And how would we teach when to use u8 (or u8t or whatever naming we use) instead of uint8_t? That’s easy if u8 behaves differently than regular ints (no narrowing): Always use u8! It’s the better int!