The Go compiler has no warnings, so that's not an option.

I guess a compiler error would be an option, but I'm not sure if that's possible to do as part of Go1. For example, what if a new standard library package is added? Should those packages break in people's GOPATHs all of a sudden?

There's also the question of whether this should also apply to internal packages within the standard library.

A perhaps more generic solution would be to encourage (or force) users to always use domains as the first element of their import paths, like foo.com/bar instead of foo/bar. However, that seems even less likely to happen, as I presume it would break lots of existing packages.

When the collision happened I've got compile-time errors such as:

undefined: pkgname.XXXXXX".

Maybe a good compromise would be to check if "pkgname" matches the name of a standard library package when these errors happen, and if that the case, print a final error "No XXXXXX provided by standard library package pkgname"?

Perhaps so. I'm not sure how smart should the compiler errors get. /cc @mdempsky @randall77 @josharian

If we did this it would be in cmd/go instead of cmd/compile. But this is a legitimate thing to do, so I don’t think we should make it an error. Also, I have personally used vendored versions of modified stdlib packages to incorporate fixes and performance improvements that were not upstream yet.

As best I can tell, the issue is that @UsernameIsAlreadyTaken6 created a $GOPATH/src/foo/bar package; but then when they tried to use it, $GOROOT/src/foo/bar was used instead?

In practice, this doesn't happen because user import paths are rooted in a domain name, which contains a period, whereas stdlib packages don't contain periods. Maybe we should formalize that practice better with a vet or lint warning?

I thought naming my package "context" would be nice (I'm a newbie).. turns out it was not very nice.
I didn't use a domain name because it's a local project at the moment and deliberately adding a dummy domain would have been weird, but.. that's your call really.

If you tried to run "go install" in your context dir you get a good error:

$ cd $GOPATH/src
$ mkdir context
$ cd context
$ echo package context >c.go
$ go install
go install: no install location for /Users/rsc/src/context: hidden by /Users/rsc/go/src/context
$ 

(/Users/rsc/go is my $GOROOT.)

Maybe we should break "go build" too? I don't think we should make all builds trying to import the standard context break just because $GOPATH/src/context exists. And soon GOPATH will be gone anyway.

Seems like making go build and go install consistent in their error messages makes sense.

This came up again as the lack of an error leaks into downstream tooling and makes for a subpar user experience. See #53825. That was closed as a duplicate, but we may want to consider raising the priority of resolving this. Unclear who should do it, though.

This could manifest in some odd ways. Luckily, the bug I raised #56269 was an issue someone encountered when learning rather than in a production bit of code.

I know module naming says you should name it as to not cause overlap, but if you don't follow this the the following could occur:

• Company A creates a Go module but isn't interested in sharing it so just calls it floats, and they build it out with unit tests.
• Go releases a new std lib package called floats to provide some useful utilities for floating point numbers.
• Company A upgrade the version of Go.
• Company A make a change that would have failed their tests, however go test ran the std library floats package instead.

Although it is a contrived example and very unlikely, does this mean each new package in the std library is breaking backwards compatibility?

does this mean each new package in the std library is breaking backwards compatibility?

No, given #32819. As you correctly point out, without reserving dot-less import paths for the standard library, adding any new standard library package could potentially break users.