Yes, I understand that. The point was that the dependency is artificial. The methods of a generic function can be defined in any order, so B doesn’t really depend on A, it’s just forced to import foo from A to ensure that B overloads the same generic foo.
If I’m reading a file and I see the line baz(x) = foo(x), now I know that this file depends on the function foo. 
And because all functions are generic with global method tables, the actual behavior of foo depends on any number of foo method definitions which can occur anywhere before or anywhere after the line baz(x) = foo(x) (even in a different module!). An import statement like from A import foo implies that everything I need to know about foo can be found in A, but it’s just not true—not even close to being true.
(Luckily the mental burden of understanding foo(x) is not that bad, because generic functions are given generic docstring definitions that are intended to apply to each method. In other words, foo(x) has approximately the same meaning regardless of the data type of the input.)
If I have all my foo definitions in the same, flat, package namespace, I don’t think there’s any “implicit importing” going on. It’s exactly the opposite, in fact. It’s all the same namespace, so of course I don’t have to do any importing (implicit or not).