It makes logical sense to do imports that way when operator overloading exists. Otherwise your custom operators would look like:

    import other

    varA other.`+` varB

Which is very ugly. At that point, we might as well just go with the function name approach that languages like Go take:

    customAdd(varA, varB)

I suppose you could change it so operators are imported into the same namespace, and non-operators still require a separate namespace when referred to. But that makes it even more complicated in my opinion. I agree it's less obvious what's coming from where, but I think when your libraries have distinct responsibilities, it usually ends up being pretty straight-forward what function comes from where based on how it's named (if it's written well).