Interesting. I agree whole heartedly with your "clarity" sentiment, but disagree that omitting the "name space" (package name) is the way to achieve that.

If I encounter code that I'm not familiar with and it uses external libraries (nomenclature chosen to reflect the cross language nature of the issue), then I much prefer some indication of where a function or procedure comes from so I have some hope of finding documentation for it (which may be the source code).

For me the usual "the first thing is most important" seems to be adjusted in the context of name spaces so I don't have the repetition problem you mention. Guess I've developed a built in filter that kicks in in that context.

Often there is one clear and sensible name for a function or procedure so using an alternative name to avoid name conflicts reduces the value of the name. In fact I find it annoying that different languages go out of their way to use different words for the same thing, seemingly just to prove they are language X and not language Y.

Of course almost all this issue goes away if you use OO techniques. An object knows what it is and an intent with object procedures is that you use the same name for the same action in many different contexts. So the best of both is that you use name spaces to qualify constructors, then using procedure names with objects provides all the context you need to understand the provenance of the procedure call.