This is effectively the library equivalent of #24250 (from both an implementation and docs perspective)

I don't think this actually has much to do with #24250: that issue is about what happens in module mode (and does not modify GOPATH/src), whereas this one is about what happens in GOPATH mode (and doesn't really affect the semantics of module mode).

FWIW, there is already a difference in instructions: users of a library in module mode will generally not need to run go get at all. So the documentation would be more like:

### To use:
import "github.com/google/go-github/v18/github"

### To install:
(Only necessary if Go modules are not enabled.)
go get -u github.com/google/go-github/github

One final note: any change here would either require backports or introduce behavior in GOPATH mode that only affects versions of the go command that also support module mode. The latter option seems a little strange to me.

@bcmills

This is effectively the library equivalent of #24250

I don't think this actually has much to do with #24250:

I honestly can't tell you what I was thinking when I wrote that!

The module vs non-module import path magic is necessarily incomplete. You cannot use a go command in GOPATH mode and pretend to have full support for semantic import paths. The special case we added is limited, to avoid ambiguity. The limitation is:

In module-aware code (a .go file within a tree with a go.mod file), an unresolvable import with a version number will be tried again after removing the version number.

This does not apply to anything else but that special case. In particular it does not apply to any command line usage, not to go get, not to go list, not to go anything.

It's just not a goal to try to make GOPATH mode "more like" module mode. I think that will lead to more confusion than anything. The GOPATH-mode name for that package does not have a v18 in it.