Comment 1:

Another way to access the path expansion from outside the go tool is to invoke "go list".
I'll say from the outset that it's unlikely this will end up in the standard library,
and so the go tool itself wouldn't be able to use it even if it were available. If you
want to make it available now, put it in an external package available via "go get".

Labels changed: added release-none, repo-main.

Comment 2:

Using "go list" was already suggested to me by the golint maintainer
golang/lint#67 but I am sure that this will lead to open issues
concerning not finding the (correct) "go" executable. I also find it messy to rely on a
not normed output format of another tool.
Putting this in a public API would define a quasi standard for Go tools and it could be
also used by other official tools like gofmt and govet.

Comment 3:

(shameless plug) At https://github.com/kisielk/gotool we maintain copy&pasted exported
versions of functionality that the go command uses. Currently it only exports
ImportPaths, more would be added by request.
In my opinion, however, this is only a workaround. Having go tool related functionality
either in the standard library, or the go.tools repository (even though then the go tool
itself couldn't use it) would encourage writing 3rd party tools that behave correctly,
i.e. support the same functionality and input that the go tool supports. Right now,
everyone is writing their own code -- some tools do not support the "..." pattern, for
example.
As an aside, however, the format of "go list" can be normed however you want, it accepts
a template as one of its arguments, that specifies exactly what it outputs. And its
default output is also documented.

I think the current plan would be to use go/packages.

Agreed; go/packages should address exactly this use-case.