There's a number of senses of the word "namespace". In C, for example, structs are in a different namespace to local variables - traditionally, you'd refer to "struct mystruct" rather than just "mystruct". I forget for current C, but in C++ you can normally (but not always) drop the word "struct" - the struct namespace leaks, but only when it doesn't cause ambiguity.
I think moz is about right for naming convention "namespaces" like this.
Name prefixes are common in C to avoid ambiguity when multiple libraries are used together. Making those prefixes semi-optional makes sense in that context. Modules have been around for a long time in some languages, and obviously at a superficial level do the same thing - but the "prefix" is typically optional. C++-style namespaces are somewhere in-between - a kind of module that isn't a module.
So yes, I suspect there was a kind of "OK - modules can help fix this problem we have, but we don't really need modules because we have #include and classes already - let's adapt" logic to C++ namespaces.
Of course, as it turns out, #include and classes don't solve all your modularity issues, even with namespaces - but that's another story.