If I understand correctly, you’re proposing looking at the call stack and using the module of the calling code. If so, mentioning the “AST” here is incorrect, as the call stack is a dynamic property, not a static/syntactic property. You cannot determine the caller of a function by looking at ASTs.
This is closely related to the notion of “dynamic scope” (as opposed to lexical scope), where variables are looked up in calling scopes. A general problem with such approaches is that they make it hard to reason about code. If I write
f() = sum([1,2,3])
in my package, I intend for f() to return 6. In your proposal, unless I misunderstand it, I have no idea what f does. If it’s called from a package that defines sum(x) = 42, or a+b = 42, then f() will return 42. Yes, currently it’s possible to overwrite Base.sum or + of integers, but we discourage that and print a warning if you do it. But in your proposal it would just be the correct behavior to let another package replace the sum or + you intended to call.
This proposal also exposes implementation details. In the example in your second post, M needs to add using StaticArrays because N uses static arrays. That means if N decides to change its implementation to use StaticArrays, that breaks all of its users. All of its users need to add using StaticArrays in order to work again. I believe that is unacceptably non-modular and makes this proposal unworkable.