I think the statement here can be made much more precise. Here is my understanding.

Today, given:

type T1 struct {
    t2
}

type t2 struct {
    X int
    u int
}

var t1 T1
v1 := reflect.ValueOf(&t1).Elem()
v2 := v1.Field(0)
X := v2.Field(0)
u := v2.Field(1)

In the gc toolchain,

v1.CanSet() == true
v1.Type().Field(0).PkgPath == nil // nil usually indicates exported name
v2.CanSet() == true // usually unexported cannot be set
X.CanSet() == true
u.CanSet() == false

In the gccgo toolchain,

v1.CanSet() == true
v1.Type().Field(0).PkgPath != nil // unexported name "t2"
v2.CanSet() == false
X.CanSet() == false // uses of encoding/json and encoding/xml expect true here
u.CanSet() == false

The fundamental problem here is that a Go program's source code can refer to t1.X (implicitly t1.t2.X) directly, while the reflect API cannot. The reflect API requires stepping into each field explicitly. The gc implementation allows reflection to set t1.X by recording the field t2 as exported (wrong): that makes it possible to set t1.t2.X (arguably right) but also all of t1.t2 (wrong). The gccgo implementation records t2 as unexported (right), which disallows setting t1.t2.X (arguably wrong) and also disallows setting t1.t2 (right).

The proposal is that both implementations record t2 as unexported, and then change reflect to record whether a value like v2 is read-only only because it is an unexported embedded field. In that case, accessing an exported element within would clear the read-only bit. The effect would be that t2 is record as unexported (right), t1.t2.X is settable (arguably right), t1.t2 is not settable (right), and of course t1.t2.u is also not settable (right).

That is, under this proposal:

v1.CanSet() == true
v1.Type().Field(0).PkgPath != nil // unexported name "t2"
v2.CanSet() == false
X.CanSet() == true
u.CanSet() == false

That satisfies encoding/xml and encoding/json, disallows most of what is incorrectly allowed in the gc toolchain today, and allows what is arguably incorrectly disallowed in the gccgo toolchain today.

Both encoding/json and encoding/xml assume today that if f.PkgPath != nil then the field is unexported and must be ignored. That test needs to be revised to f.PkgPath != nil && !f.Anonymous, so that they do try to walk into the embedded fields to look for unexported fields contained within. Any similar external packages would need the same ~1 line change. The new condition is correct both before and after the proposed change, so it could be made by any affected packages independent of the eventual Go 1.6 release.

Thanks for the much clearer reformulation Russ.

Preparations for json and xml package:
https://go-review.googlesource.com/#/c/14011/
https://go-review.googlesource.com/#/c/14012/

See the actual change:
https://go-review.googlesource.com/#/c/14010/

Note that the tests added in the json and xml CLs will currently break for gccgo.

Packages just checking for f.PkgPath to determine if a field is exported should implement a fix similar to those in 14011 and 14012 now to prevent breaking when CL 14010 is checked in.

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

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

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

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

Code that assumes

f.PkgPath != nil 

means a field is unexported and must be ignored must now be revised to check for

f.PkgPath != nil && !f.Anonymous

for it to walk into the embedded structs to look for exported fields contained within.