Go code is organized into "packages". E.g., <http://bazil.org/fuse|bazil.org/fuse> or os/exec. Each package is on its own. Except that often nested packages come from the same source. So <http://bazil.org/fuse|bazil.org/fuse> and <http://bazil.org/fuse/fs|bazil.org/fuse/fs> come from the same tarball. We make this work at twitter by putting the lines in our pants.ini for matchers. (Grep for <http://bazil.org/fuse|bazil.org/fuse> to see this.) This has some weirdnesses in pants world because we cannot go directly from the go package name to the target address in the BUILD space because <http://bazil.org/fuse/fs|bazil.org/fuse/fs> is from 3rdparty/go/bazil.org/fuse:fs , not 3rdparty/go/bazil.org/fuse/fs: (notice the different placement of the colon).
There is code in pants's go fetcher to try and guess what target it comes from to help you debug undeclared dependencies. This code is at <https://github.com/pantsbuild/pants/blob/7a7f51390cacd82a3e982eaf4516c510f23092c0/contrib/go/src/python/pants/contrib/go/tasks/go_fetch.py#L189> . This may be causing resolution to find the synthetic target instead of the declared target. (The synthetic target has no explicit revision set; the explicit target has a revision set).
There is one more issue: the code for <http://bazil.org/fuse|bazil.org/fuse> is currently hosted at github. Go supports this by using a protocol of looking for meta tags in the html of the former that redirects you to the latter. Support for this was recently added to pants and may be contributing to the change in behavior. That happened in <https://github.com/pantsbuild/pants/commit/7a7f51390cacd82a3e982eaf4516c510f23092c0>