Consider the following snippet:

type embed struct{ X int }
type S1 struct{ embed }
type S2 struct{ *embed }

v1 := reflect.ValueOf(&S1{}).Elem().Field(0)
v1.Set(reflect.ValueOf(embed{}))  // OK on Go1.0..Go1.5; Panics on Go1.6..present
v2 := reflect.ValueOf(&S2{}).Elem().Field(0)
v2.Set(reflect.ValueOf(&embed{})) // OK on Go1.0..present

We have two different structs S1 and S2 that differ only in that one has a embedded pointer, while the other does not. Note that embed is an unexported type, and so acts an unexported field in S1 and S2.

From Go1.0 until (and including) Go1.5, you could call Set on the unexported field embed on both the embedded value and embedded pointer versions.

From Go1.6 until (the present day) Go1.9, you could call Set only on the embed field only if it were pointer version, but reflect would panic if you tried to call Set on the pointer version. This is a result of a change to the policy mentioned here.

Outside of reflect, the Go language forbids you from directly setting S1.embed or S2.embed from an external package. For this reason, I'm inclined to believe that the current behavior of reflect is a bug since it permits you to do something that the language forbids.

However, there is an implication to this change. It means that JSON cannot be round-trip marshaled and unmarshaled. For example:

in := &S2{&embed{5}}
out := &S2{}

b, _ := json.Marshal(in) // string(b) == `{"X": 5}`

// Panics, since out.embed is nil and it cannot initialize that field.
json.Unmarshal(b, out)

// Manually allocated embed would allow this to work:
out.embed = &embed{}
json.Unmarshal(b, out)

There would need to be a fix to the json package to avoid a panic in this situation.

If we accept my fix to #21122, then this will also be fixed.

\cc @ianlancetaylor