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

$ go version
go version go1.17.2 linux/amd64

Does this issue reproduce with the latest release?

This is the latest release

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

$ go env
GO111MODULE=""
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/fishy/.cache/go-build"
GOENV="/home/fishy/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/home/fishy/.gopath/pkg/mod"
GONOPROXY=""
GONOSUMDB=""
GOOS="linux"
GOPATH="/home/fishy/.gopath"
GOPRIVATE=""
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/nix/store/vydvhfg076dfchm93hn96li2k1jqh04n-go-1.17.2/share/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/nix/store/vydvhfg076dfchm93hn96li2k1jqh04n-go-1.17.2/share/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.17.2"
GCCGO="gccgo"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/home/fishy/work/test-go-mod-retract/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-build3897776340=/tmp/go-build -gno-record-gcc-switches"

What did you do?

This is forked from the discussion of #34055 and is an issue currently affecting Apache Thrift.

I made a minimal reproducible example at https://github.com/fishy/test-go-mod-retract to demonstrate the issue, but the high level summary is:

1. The project made a mistake by adding go.mod to a subdirectory, without realizing the consequences of that.
2. The project realized that's a mistake, removed the go.mod in the subdirectory and added go.mod to the root directory instead.
3. The action in 2 doesn't fix the issue totally. the version with go.mod under the subdirectory will be recognized by go toolchain (and pkg.go.dev site) as the "latest" version, over whatever git semver tag you tagged at the project later (for example, if you go to https://pkg.go.dev/github.com/apache/thrift@v0.15.0/lib/go/thrift, it will tell you that it's not the "latest" version).
4. Even if you try to retract that version from root go.mod file, it won't work (as I demonstrated in the test-go-mod-retract repo).

What did you expect to see?

Either:

1. We are able to retract a version from a previous, subdirectory go.mod file, from the root go.mod file

or

2. Provide a way to retract the whole go.mod file (e.g. we can add the subdirectory go.mod saying "every previous version coming out of this go.mod file are retracted and this go.mod file should be ignored")

What did you see instead?

The consequences of the mistake of adding subdirectory go.mod file lasts forever with no way to fix completely.