This is a bug that's been around for a long time - no need to fix for 1.7. Should address this in new export format only after the textual export format is gone to avoid "mixed-mode" errors. Leaving for 1.8.

I cannot reproduce this anymore with Go1.6 (I don't think it was present in 1.6, the error case was probably flawed due to a buggy exporter/importer at that time).

This bug also doesn't exist in Go1.7 - at least given the above testcase. In fact, it happens to have been fixed inadvertently by https://go-review.googlesource.com/#/c/22714/6 ; specifically: https://go-review.googlesource.com/#/c/22714/6/src/cmd/compile/internal/gc/bimport.go, line 521:

The exporter doesn't export a package for the (unexported) _ field. The importer uses the builtin package for the _ field. Since any local struct type using a _ field will use the local package for _ field, an anonymous struct with a _ field and a structurally equal imported struct with _ field will have different packages for that field, leading to the expected error.

But the "optimization" of using the builtin package for imported _ fields is still incorrect because it's possible to export unnamed structs with _ fields which should also not be assignment compatible. Here's a test case:

$ cat a.go
package a
type A struct { _ int32 }

$ cat b.go
package b
func B() (_ struct { _ int32 }) { return }

$ cat c.go
package c
import "./a"
import "./b"
var _ a.A = b.B() // <<< assignment should fail

Here's another test case:

$ cat a.go
package a
func F() (_ struct { _ int32 }) { return }

$ cat b.go
package b
func F() (_ struct { _ int32 }) { return }

$ cat c.go
package c
import "./a"
import "./b"
var aa = a.F()
var bb = b.F()
var _ = aa == bb // <<< comparison should fail

go/types reports an error in this case when type-checking c.go:

$ gotype c.go 
c.go:6:9: cannot compare aa == bb (mismatched types struct{_ int32} and struct{_ int32})

which is correct. go/types can report an error because its importer assigns the package from which the struct is imported to the struct's _ field. (That's not correct in general either, because a struct may have been imported transitively and then gets the last package rather than the original one. But fixing this bug for cmd/compile in the export data will also fix this case for go/types).

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