latest is not a semantic version: it is (at best) a tag or branch name, and should be resolved to an actual semantic version or pseudo-version whenever a go command is run within the golang.org/example/b module.

Is this a theoretical problem, or did you encounter this in a real-world scenario? If the latter, did someone commit a go.mod file without actually running, say, go test or go build on it?

This is a "real-world scenario", except with the "someone" being me. I'm still a way's off from being able to tag stable versions, and I don't really want to have to bump go.mod in b every time a changes. Recently I wanted to start playing with a c use case, which depends on b, and I ran into this snag. The behavior I'd expect is for all of the latest markers and such to be resolved once on the first go build, similar to what happens when you only have a b depends on a with no c in the picture. The hard part about implementing this, I would imagine, is that when c depends on b, b's contents are supposed to be immutable, which means at present afaict there's no place to put a resolved go.mod for the intermediate b.

One of the design goals of modules is to enable fully-reproducible builds, and leaving label and branch-names such as latest unresolved would be antithetical to that goal.

You could leave a out of b's go.mod file entirely, in which case c would have to re-resolve it (and would resolve the latest version by default). However, it seems simpler to leave the dependency on a at whatever you tested b against: you can always upgrade above that explicitly in module c (by running go get golang.org/example/a within that module).

@zx2c4, does the above approach satisfy your use-case? (If not, what are the remaining problems?)

Timed out in state WaitingForInfo. Closing.

(I am just a bot, though. Please speak up if this is a mistake or you have the requested information.)