extern(C++, ns)

[Daniel Murphy via Digitalmars-d]

On 18/01/2016 6:47 AM, Walter Bright wrote:
 > On 1/17/2016 3:55 AM, Daniel Murphy wrote:
 >> So now we have two public symbols called 'mylib', and because they
 >> conflict they
 >> can't be used to disambiguate eg 'someotherlib.funca' with
 >> 'library.a.funca'.
 >
 > Consider these two C++ files:
 >
 > ------file 1-------------
 > namespace (X) { int fooa() { ... }
 > ------file 2-------------
 > namespace (X) { int fooa() { ... }
 > -------------------------
 >
 > You'll get a multiply defined symbol error for X.fooa() from the linker.
 > When using namespaces in D, the "one definition rule" needs to be
 > followed just as in C++ for the same reason.
 >
 > However, in D, you CAN do the following:
 >
 > -----module M-----------
 > extern (C++,X) { int fooa(); }
 > -----module N-----------
 > extern  (C++,X) { int fooa(); }
 > ------------------------
 >
 > and yes, M.X.fooa() will wind up referring to the same externally
 > defined symbol X::fooa() as N.X.fooa().
 >
 > Because, as I said multiple times, namespaces in D affect the name
 > mangling in a C++ way while doing symbol lookup in the D way.
 >
 > Note that
 >
 >     extern(C) { ... }
 >
 > in D works EXACTLY the same way.

So???? Why make extern(C++, namespace) introduce a new symbol? Why not 
just let it change ONLY mangling and use modules to organize symbols and 
resolve conflicts?