It looks like you're choosing to overload the terminology of both "namespace" and "module." It shouldn't be any surprise that you see things as "indirect" when they don't fit your definitions.
In most languages that support namespaces, including C#, a namespace is not a module. A namespace is a way of scoping names. Modules are a way of scoping behavior.
In general, while the .Net runtime supports the idea of a module (with a slightly different definition than the one you are using implicitly), it's rather rarely used; I've only seen it used in projects built in SharpDevelop, mostly so that you could build a single DLL from modules built in different languages. Instead, we build libraries using a dynamically linked library.
In C#, namespaces resolve without any "layer of indirection" as long as they are all in the same binary; any indirection required is a responsibility of the compiler and linker that you don't have to give much thought to. Once you start building a project with multiple dependencies, you then reference external libraries. Once your project has made a reference to an external library (DLL), the compiler finds it for you.
In Scheme, if you need to load an external library, you have to do something like (#%require (lib "mylib.ss")) first, or use the foreign function interface directly, as I recall. If you're using external binaries, you have the same amount of work to resolve external binaries. Chances are you have mostly used libraries so commonly used that there's a Scheme-based shim that abstracts that from you, but if you ever have to write your own integration with a 3rd party library, you'll essentially have do some work to "load" the library.
In Ruby, Modules, Namespaces, and File Names are actually far less connected than you seem to assume; the LOAD_PATH makes things a bit complicated, and Module declarations can be anywhere. Python is probably closer to doing things the way you think you are seeing in Scheme, except that 3rd party libraries in C still add a (small) wrinkle.
Additionally, dynamically typed languages like Ruby, Python and Lisp typically don't have the same approach to "contracts" as statically typed languages. In dynamically typed languages, you usually only establish a sort of "Gentleman's agreement" that code will respond to certain methods, and if your classes appear to be speaking the same language, all is good. Statically typed languages have additional mechanisms to enforce these rules at compile time. In C#, using such a contract allows you to provide at least moderately useful guarantees of adherence to these interfaces, which allows you to bundle plugins and substitutions with some degree of guarantee of commonality because you all compile against the same contract. In Ruby or Scheme, you verify these agreements by writing tests that work at runtime. There are costs and benefits to either solution, but conflating the idea of a namespace, a module and a library won't help.
There is a measurable performance benefit from these compile time guarantees, as a method invocation requires no double dispatch. In order to get these benefits in something like Lisp, Ruby, JavaScript, or elsewhere, what are now still slightly exotic mechanisms of just-in-time statically compiling classes in specialized VMs is required.
One thing that the C# ecosystem still has relatively immature support for is the management of these binary dependencies; Java has had Maven for several years to deal with making sure you have all your requisite dependencies, whereas C# still has a fairly primitive MAKE-like approach that involves strategically placing files in the right place ahead of time.
