Comment 1:

The problem here is that your program also imports math/rand, so the Go command tries to
build both math/Rand and math/rand, having checked that both directories contain package
sources. What it doesn't know is that they're the same directory. Worse, when it tries
to build the two - in parallel - it writes one to $WORK\math\rand\obj and the other to
$WORK\math\Rand\obj. Of course, those are the same directory too, so the one compilation
is overwriting the first's files as the first tries to pack them into an archive. That
causes the pack errors.
I suppose one solution is to use SameFile to decide if two directories are the same, but
that will be system dependent.
Another possible solution is to reject any program that imports (perhaps indirectly) two
paths that differ only in case. That's what I'm leaning toward right now.
Thanks for the report.

Labels changed: added priority-later, go1.1, removed priority-triage, go1.1maybe.

Owner changed to @rsc.

Status changed to Thinking.

Comment 2:

I unfortunately don't know enough of the specifics, but is there a way to force the
existence check on the exact characters/runes? I'm just thinking there my be similar
issues that don't involve case, for example é and e. 
Do you know if there would be a similar issue with files within a package? Windows
doesn't let me create a foo.go and Foo.go in the same package, but could in happen in
other OSes? Maybe you also need to forbid (already are forbidding) two .go files that
only differ in case.

Comment 3:

I think SameFile is more dependable. "case dependency" will help here, but we will
discover different scenarios. Better be safe then sorry.
If people have foo.go and Foo.go in the same package and come to build it on windows,
then they are looking for trouble. Nothing Go can do about that.
Alex

Comment 4:

This issue was closed by revision 2d41645.

Status changed to Fixed.

Comment 5:

SameFile is not helpful here, because it varies from system to system. The goal is to do
something that will catch all the SameFile cases (or at least all the ones that will be
encountered in practice), even on case-sensitive systems, so that people do not
inadvertently create packages that cannot be built on Windows.