To continue using your git submodule layout while using modules, I think you can add a replace line to go.mod for each of the modules that reside in there, with a relative path starting with ./. Might be less confusing to combine that with a move from vendor/ to third_party/.

Unfortunately, "classic" vendor lets you end up with multiple copies of different (or even identical) minor versions of a package in the same build, which causes all manner of headaches. Adding that to module mode would introduce a special case that violates one of module mode's basic guarantees.

The applications have grown and adapted these structures over time based on the features available in the compiler until now, and the fact that until recently there was no 1st party solution for package management.

I apologize for the work you'll need to do to deduplicate your vendor directories into a single top-level vendor directory. All I can say is that if you make each one use a go.mod instead of vendor, that will set you up much better for understanding which code versions you are actually using, for updating in response to security fixes, and so on. It really does lead to a better, more agile setup.

I would push back a little on the "until recently" part. Go modules were first made available for use in Go 1.11 (August 2018), and we announced our intent to remove GOPATH in the "Go Modules in 2019" blog post (December 2018). Also, Go 1.16 will be supported until the release of Go 1.18 (~February 2022).

Removing the ability to resolve code in this way feels inconsistent with the spirit of the below paragraph taken from the go1compat document, which I appreciate people are likely familiar with.

Note also that the document explicitly excludes tools such as the Go command. It is concerned with the Go language and the standard library.

We do try to follow the spirit of the document generally, and again we are aware that it is painful to update old code trees. We don't intend to make a break like this again any time soon, if ever. But this one really is necessary for the progress of the Go ecosystem.

@rsc You statement assumes that people always uses other dependencies or such dependences always have version problems. But these simply are not always true. When those cases don't occur, it is unnecesary to enforce all Go code must be in a module. For this reason, the classical behavior should be maintained.

I believe this won't happen, and some basic level of GOPATH support will remain indefinitely.