Here's another test case that doesn't do the right thing AFAICS, although this one fails under Go 1.12 too:

https://play.golang.org/p/qDuD3BjVlmx

Note that commit 623b5a2f4d2a has v2.0.5 in its history, so I think the resulting version should be v2.0.6-0.20181027085611-623b5a2f4d2a+incompatible, not v0.0.0-20181027085611-623b5a2f4d2a.

I can't reproduce the observed behavior with a clean module cache:

example.com$ gotip version
go version devel +ab724d43 Mon May 20 20:58:14 2019 +0000 linux/amd64

example.com$ gotip mod init example.com
go: creating new go.mod: module example.com

example.com$ gotip get github.com/davecgh/go-spew@d8f796af33cc
go: finding github.com/davecgh/go-spew d8f796af33cc
go: downloading github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc
go: extracting github.com/davecgh/go-spew v1.1.2-0.20180830191138-d8f796af33cc

I suspect that you've got a v0.0.0-* entry in your module cache, perhaps due to an older pseudo-version specified in the (transitive) requirements of some module you've built previously. If so, that would make this another instance of #27171. Could you confirm?

The v2.0.6-[…]+incompatible issue is #29262.

I've just tried it again this morning and I can no longer reproduce the issue, sadly. I haven't changed my cache settings. There's something odd going on. For future reference though, when you talk about the "module cache", you're talking about what's in $GOPATH/pkg, not $GOCACHE, right?

I'll close the issue for now.

For future reference though, when you talk about the "module cache", you're talking about what's in $GOPATH/pkg, not $GOCACHE, right?

Correct.