Your contrived example doesn't initialise the embedded struct that also contains a "Burrow" field. If it did that at all, even without naming the Burrow field... you would not be allowed to initialise the struct, because of the ambiguity.
https://go.dev/ref/spec#Composite_literals
> A key must not denote a promoted field inside an embedded struct if that struct is also specified by another key.
> Given the declarations
type Object struct { name, color string }
type Point3D struct { Object; x, y, z float64 }
type Line struct { Object; p, q Point3D }
obj := Object{"edge", "black"}
line3 := Line{Object: obj, name: "diagonal"} // invalid: name denotes a field inside Objecthttps://go.dev/play/p/CFWVXkFBOEX
Note that I added a name field to Line.
Data: {edge black} -- {{edge black} {{ } 0 0 0} {{ } 0 0 0} diagonal}
./prog.go:20:29: cannot specify promoted field name and enclosing embedded field Object
The whole point is the implicit bug, when the field is added and initialisation code rewritten to take advantage of this feature, without the developer realising the clash in first place.
The rule errs in favour of the developer and the struct they can see. Initialising (or accessing!) a named field always picks the one in the top-level struct if you have one there. It'll be there because you added it. Promoted fields can only get promoted if they are unambiguous.
If you don't want to take advantage of that, you can write in full:
g := Gopher{
Name: "Gopher",
Burrow: "Burrow #42",
Habitat: Habitat{Burrow: "Wild Acres"},
}
fmt.Println("Your burrow: ", g.Burrow)
fmt.Println("I mean your _real_ burrow: ", g.Habitat.Burrow)
Most of them are very happy that they can embed some other type they don't know the full contents of, knowing they can access (and now initialise!) fields in it they care about, and thus don't give the fields in their own types the same name, while resting assured that if that other type later gains new fields they've never heard of, it's not going to clash with their own naming choices and break their code and force them to rename something. Their types' field names always come out on top, in their code.
You're doing "but what if I deliberately named my type's fields the same as the embedded type's fields?", which is like "but what if I deliberately stuck my hand in the meat grinder?" -- don't do that
However I see that I crash again in the Go versus other programming languages ecosystems mindset.
I understand the need not to break existing code that might have such fields.