My scenario:

1. Two libraries: bot and hop
2. hop imports bot as a dependencies
3. bot uses hop as a dev dependency to run test tasks, among other things
4. I'm trying to move a method topoSort from hop to bot
5. Adding topoSort to bot creates a collision in hop, but I don't see it in the editor...it's not reporting issues with imported libraries
6. My tests crash claiming topoSort doesn't exist...when really I have 2 (!!!)

This comment was originally written by @mhausner

From the VM's perspective, the NSM is the right behavior. The spec says:

If a name N is referenced by a library L and N is introduced into the top level scope of L by more than one import, and not all the imports denote the same declaration, then:
A static warning occurs.
If N is referenced as a function, getter or setter, a NoSuchMethodError is raised. <<====
If N is referenced as a type, it is treated as a malformed type.

Added AsDesigned label.

Pushing this to a spec bug

In a world with lots of imported libraries, the chance that a pub update brings in a silent name conflict is huge.

The current error offers little help to end users or library authors.

cc @mhausner.
Removed Area-VM label.
Added Area-Language, Triaged labels.

An implementation could choose to define a subclass of NoSuchMethodError, say NoSuchMethodDueToAmbiguityError, that indicated that the method was absent because of an ambiguity . It might even say what the source(s) of ambiguity were.

In other words, there isn't a real need to change the spec (besides, that isn't so easy any more; it will have to pass the standards committee).

And so, I am ping-ponging this back to the VM team.

Removed Area-Language label.
Added Area-VM label.

This comment was originally written by @mhausner

No bug here.

Added AsDesigned label.