Same reasoning applies to new keywords.

It sounds like you got some refactoring to use since you didn't namespace your own core types?

C doesn't have namespaces.

The only sane way to deal with name collisions is either to use C stdlib types in library APIs (e.g. uint8_t), or use a library specific prefix (e.g. mylib_u8) - which is of course even more awkward than just using the standard uint8_t.

A prefix and a namespace aren't really that different in practice.

They are different. Namespaces are syntactically enforced and you can opt-in or out to names. To have syntactically validated qualified access.

Naming might go well and have the same utility, but you never know what evil things are going on in all those headers, redefining each other's symbols and yours.

You seem to be focusing on specific problems with C/C++. I don't really care about that, all I'm saying is that prefixing names are equivalent to placing them within a namespace, in practice, and theoretically come to think of it. You can easily define a bijection between namespaced symbols and prefixed symbols. Requiring the full prefixes are simply a tad more verbose, essentially equivalent to using a fully qualified name for symbol.

I think that "namespacing" basic types such as u32 is completely unecessary.

In what world would an u32_MYLIB would be different than an u32_SOMELIB?

Basic types are common enough.

The preprocessor doesn’t know that u32 defined in foo.h is the same type as u32 defined in bar.h. So you’ll get an error when importing both.

If C made this change, it could also make it legal to redefine u32 etc as appropriate integer types any number of times without erring.

This would break legacy code. I had one employer with a bool type that was a 32-bit integer because of obscure alignment issues. This is why _Bool exists and the bool typedef has to be brought in explicitly with stdbool. You can't just go and usurp popular short type names. The standard reserved *_t and _[A-Z].+ for this purpose. People have been writing portable code with the expectation that future standards aren't going violate that promise and break things.

This is just one of the reasons that new languages that dispense with outdated assumptions and insted make assumptions more suitable to our times are a good thing. C and C++ are really old and some things can not be fixed with libraries.

foo.h defines i64 as “long” and bar.h defines it as “long long”. Now what?