Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version devel +9ef5ee911c Tue Aug 7 14:36:14 2018 +0000 linux/amd64

Does this issue reproduce with the latest release?

N/a - working with tip.

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN="/home/myitcv/.mountpoints/x/src/myitcv.io/.bin"
GOCACHE="/home/myitcv/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/myitcv/.mountpoints/x"
GOPROXY=""
GORACE=""
GOROOT="/home/myitcv/gos"
GOTMPDIR=""
GOTOOLDIR="/home/myitcv/gos/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/myitcv/.mountpoints/x/src/myitcv.io/go.mod"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build953293682=/tmp/go-build -gno-record-gcc-switches"

Currently the replace directive is specified as:

The -replace=old[@v]=new[@v] and -dropreplace=old[@v] flags add and drop a replacement of the 
given module path and version pair. If the @v in old@v is omitted, the replacement applies to all 
versions with the old module path. If the @v in new@v is omitted, the new path should be a local 
module root directory, not a module path. Note that -replace overrides any existing replacements 
for old[@v].

As @mvdan and I were just discussing, when working on a mono-repo with multiple submodules and dependencies between those modules, changes to the submodules will need to be sequenced in such a way that it results in separate commits in the remote VCS.

One way of achieving this sequencing is via separate local branches (that ultimately get merged/cherry-picked/whatever on the remote).

Which raises the question of whether we could/should support a replace directive to a local directory which can also accept a branch name (else the local branch changes would need to be pushed to a remote repo to enable a branch specification, i.e. we can't fully develop offline).

One further nuance would be that a local directory@branch specification would not resolve to a commit, and instead would always refer to HEAD (or equivalent)

I realise this creates an ambiguity with the current old[@v] semantics (because the absence of version on the "old" portion of a replace indicates it will be a filepath), so just wanted to float the idea first.

/cc @rsc @bcmills