Asking in the ML the answer is quitte evident.

Vgo implements a package manager which is suppose to download dependencies
from some remote host.
It determines where to fetch the code by looking at the import path of the
dependency.
Hence All dependencies which are managed with the new vgo mechanism musst
follow this import path convention.
Other dependencies are either the std lib, I guess this is a special case

I let open this issue to maybe put it in the FAQ.

I disagree with the assertions does in that ML thread. vgo should support pure local development just like the go tool does. And mylib could also well be an internal server, even if it doesn't contain a dot. This is a bug.

Using dotless import paths for your own projects is just as bad of an idea as using the .dev top-level DNS domain for development was. If the stdlib ever adds a package named mylib, things break. Use proper namespaces, even if your names aren't visible to anyone outside your organization.

I'm agree but dotless import path is in many places in the official documentation for a starting project... Also mentioned as a practice at Google !
https://golang.org/doc/install#testing
https://blog.golang.org/organizing-go-code

Without GOPATH it can be more tempting also.

@flibustenet Those links very much encourage the github.com/golang/example style. I'm willing to concede that dotless imports seem to be unfortunately used, but please let's not encourage them.

(Side note, Google internal usage is probably irrelevant, as as far as we on the outside know they don't use the go build system anyway.)

The go build system already assumes in some places the dotless prefixes mark the standard library, so @tv42 is right that using it places you on thin ice. At the same time, I don't think this specific failure is too hard to fix, so we can look into fixing it.

If it's too hard to fix, though, we'll just mark it working as intended.

Change https://golang.org/cl/107661 mentions this issue: cmd/go/internal/vgo: allow dotless module paths if replaced