Proposed fix https://go-review.googlesource.com/#/c/16475/

CL https://golang.org/cl/16475 mentions this issue.

Your example seems to rely on manipulating the GOPATH so that one package is seen in one case and a different package with the same apparent name is seen in a different case. It's not obvious to me that it's important for the go tool to try to defend against people who do this kind of thing. You could do exactly the same thing by simply replacing the .a file. Your proposed CL makes that a bit harder, because now I can't just replace the .a file using cp, I have to actually edit the .a file to change the build note value.

Can you explain why this is worth changing?

I consider this issue worth fixing, because it ensures the program as a whole is well-typed, that whatever type-safety assertions the compiler made, while compiling an individual package, still hold at the time of linking.
That said, indeed, it is not possible to prevent users from making a conscious effort to subvert the Go type system, this change makes is harder for such accidental errors to go undetected.

I don't think this has anything to do with type safety of Go.

The ultimate goal of type-safety is to produce an executable, free of type errors. A type-checked
object or a library are of little value, as they aren't executed. Thus, achieving type safety is a task for the whole toolchain and runtime, not only for the compiler. I don't claim that this is an issue of the Go language, but with the "go" toolchain.

You're manipulating the objects behind the compiler's back.

I'm sorry, I'm not manipulating objects. I'm manipulating GOPATH, which is supposed to be
manipulated by users.

Actually you don't even need to have two GOPATH to do this.

OK, multiple different ways, by which one can achieve the same bad result just increase the severity of the problem.

The proposed change also introduces a major problem:
two different builds of the same package will produce
different buildID, so we lost the ability produce identical
binaries given identical inputs: the toolchain is no longer
deterministic.

"toolchain is no longer deterministic" is quite a statement, the output consist of eight concrete non-deterministic bytes, the rest is deterministic.

How is that property used at the moment? Whatever procedure compares the outputs of two builds,
isn't it possible to modify it, so it can determine if the difference is only is in specific eight bytes
in the whole output and reach to the same conclusions as before?

To really fix the problem without breaking the deterministic
constraint is very hard, we basically have to include a hash
of the source code into the buildID (just hashing the exported
interface is not enough, because it's possible to only change
the internal implementation of some non-exported functions
and achieve the same arbitrary memory read).

Yes, but hashing the entire source was already considered unacceptable tradeoff wrt. build speed,
which was one of things that I took into account when thinking of the various ways to fix this issue.

Every language that supports separate compilation is vulnerable to the issue you describe. I don't think this is serious or worth fixing. Sorry.

Simple deterministic output is a highly desirable property.