In Go, package name should be the same as repo name.
Most cases that I've seen are not including "go" in repo name to resolve naming conflict but "just because", possibly cargo-culting others that did it.
I recognise that you don't speak for the entire Go community, but frankly this kind of over-prescriptive preference presented as the only possible way forward is oddly common in what often seems more like a church than a programming language ecosystem.
Go is just a tool, like any other. If I happen to use git for versioning that's my choice, and I (and everybody else) can and should name and arrange repositories as is convenient.
There is no "in Go" to be had here; merely "in my project as makes sense for me".
I'm not sure if you actually disagree with me.
Like I said, most of the time I see "go" in project name, it's not because the owner of the repo was in the hypothetical situation you describe.
So unless you think it's ok to add "go" to the name of the repo willy-nilly there's no disagreement.
I'm not sure I understand how that's an argument in itself for using "go-" or "-go" (or some other version) in a package name. It results in a lack of clarity in how to reference the package: the hypothetical "github.com/stripe/stripe-go" import path probably (and almost certainly) introduces the "stripe" package name, but the the discordance between what you write as an import statement and by what name the package is referenced is unconventional and strange.
There are certainly times when it makes sense. And I agree with the idea that an organization, in most cases, shouldn't come up with a unique name for the Go implementation of, say, an API wrapper, just to satisfy Go convention. But generally speaking the convention should be followed not simply because it's prescribed but because it's sensible to avoid that disconnect between the import statement and the package name.
First of all, it's entirely possible that "go" is in the repo name, but beyond that, I regularly see packages (and very popular, mainstream packages) where the package name is not the repo name. The one that comes to mind is github.com/mattn/go-sqlite3 which provides the `sqlite3` package.
Agreed, I don't see the point of mentioning the language for compiled, stand-alone programs and standard, C-compatible libraries. The resulting binary is the same (well, of the same nature at least) whichever language it was compiled from.
It only has a use for programs and libraries in interpreted (in the widest sense of the word) languages, which can only be used together with libraries in the same language, or from programs in the same language, or with a specific external runtime or virtual machine.