I only see one good reason to introduce an additional alias: fixing some of the drawbacks of current behavior,
Then it would be a new type, not an alias.
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.
That might be least favourite of all the names so far.
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).
Except for all the other types of templates.
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!