> you can be 100% that both C and D definitely live under B

And that brings you what benefit exactly? I've seen a number of projects that are preoccupied about "proper nesting", while it is 99% bureaucratics and all those projects are still a mess.

The benefits of "living under this or that" are technically zero, and with respect to human factors are minimal given that 1) you can get most of the organizational benefits of namespaces by doing A_B_C, and 2) you can also add new members to proper namespaces from external files in most languages, including C++, so there really isn't a difference w.r.t "knowing for sure".

The benefit is a nice mental model of where what function lives (if you don‘t overdo it). This type of packaging also lends itself to module systems, a thing I desperately wish for in C

This type of "packaging" is completely orthogonal to module systems. It's merely a syntactic discipline that adds one more complication to deal with even where it has zero benefit.

You could say that the C/C++ systems already has "modules" if you look at object files and header files. Of course, they are a limited kind of modules because they are a bit low-level and C has the preprocessor problem, making it slow to "import" modules. But none of that has to do with namespaces.

Well, they enforce having a lot of project structure. Java and C# use their namespaces to ensure that everything useful is under five layers of pointless names like System.Collections.com.net.org.ArrayList.

I think not having namespaces may be an effective way to prevent enterprise programming from happening.

Yea, I‘ve got to be honest in that I don‘t understand Java or C# hierarchies.

Node.js and Rust do module systems just fine.