In implementations of the Scheme programming language (R6RS standard) I can import a module as follows:
(import (abc def xyz))
The system will try to look for a file $DIR/abc/def/xyz.sls where $DIR is some directory where you keep your Scheme modules. xyz.sls is the source code for the module and it is compiled on the fly if necessary.
The Ruby, Python, and Perl module systems are similar in this respect.
C# on the other hand is a little more involved.
First, you have dll files that you must reference on a per project basis. You must reference each one explicitly. This is more involved than say, dropping dll files in a directory and having C# pick them up by name.
Second, There isn't a one-to-one naming correspondence between the dll filename, and the namespaces offered by the dll. I can appreciate this flexibility, but it can also get out of hand (and has).
To make this concrete, it would be nice if, when I say this using abc.def.xyz;, C# would try to find a file abc/def/xyz.dll, in some directory that C# knows to look in (configurable on a per project basis).
I find the Ruby, Python, Perl, Scheme way of handling modules more elegant. It seems that emerging languages tend to go with the simpler design.
Why does the .NET/C# world does things in this way, with an extra level of indirection?
Best Answer
The following annotation in the Framework Design Guidelines Section 3.3. Names of Assemblies and Dlls offers insight into why namespaces and assemblies are separate.