Thinking about this some more, I think using the zero-version was a mistake.

Instead, we shouldn't be writing the require directive out at all: we don't know any valid version to require, and if a downstream consumer requires our module they're better off resolving latest instead.

That seems to support the second case considered in #26344 (comment): this sort of wildcard replace directive effectively means “select the latest version (none), and then select this replacement as if it were a slightly-higher version.”

Change https://golang.org/cl/220080 mentions this issue: design/36460: add design for lazy module loading

That seems to support the second case considered in #26344 (comment): this sort of wildcard replace directive effectively means “select the latest version (none), and then select this replacement as if it were a slightly-higher version.”

Thinking about this further: it is often useful (for testing) to be able to slot in dormant replace directives and then run various go get commands to see what happens. As of Go 1.16 go get correctly mixes in the replacement versions, so that actually provides a fairly high-fidelity simulation of what would happen after the replaced versions are published.

So I think this sort of “select-and-replace” form should actually have a different syntax; perhaps one derived from (or identical to) the “replacement alias” form (#26904).