> While you read a module code you don't know where the imported > names it uses come from.
That's a feature. Let me give an example. I recently wrote an OAuth implementation for my web app. I started off by writing it all in one module, the one where it was used. That was ok until I wanted to use it in a different module, so I cut and pasted it to a different file, the shared util.d. Compile, both modules now work. No need to edit the user code at all. Next up I moved it from that grab bag of project specific utilities to a generic oauth.d module, refactoring it to be generic. Add "import oauth;" and compile. All modules work without editing their code. Later, I might choose to rename it to something more generic. If I added another web mechanism, I might call it webauth.d or something like that. Aside from the import lines, the rest of the user code would confidently remain unchanged. That's the advantage a good import system like D has. You can make changes with ease and confidence knowing it isn't going to break anything anywhere else. That's really the goal of modularity: making it so a change in one place won't break code anywhere else. Using fully qualified names works /against/ that. (Note though that sometimes fully qualified names do make things more clear or show something special about that block of code. They have their uses and it makes me very happy D supports it and has static imports. But their uses are more specialized: being the default would be a net negative, for the reasons above.)