This is going to be vague; apologies.

One source of frustration when working programmatically with imports is the need to use expensive go/build.Import calls to go from a package's import path to its name.

If you have a qualified identifier of interest, you need to build.Import the import path of every un-named import spec in the file (which is usually most of them) to find out whether the package name matches. This can have disproportionate cost.

This problem is particularly acute when you want to go from package name to import paths, as goimports does. You would need to read the entirety of the GOPATH to find matching packages. For performance reasons, goimports currently declines to do this and uses some heuristics around naming conventions to cut down on the number of candidate import paths. That's fine for goimports, but not for (say) guru.

vgo seems likely to be the future source of truth about all imports of interest in a project. It seems to me this might provide an opportunity for go.mod to provide a canonical mapping between package import paths and names, one that can be consumed with minimal I/O and filesystem interaction.

@rsc @alandonovan @keegancsmith @bradfitz