I'm not sure what I can say. One man's "source of bugs" is another man's "convenient syntax".

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)

... but most Go programmers would look at the fact you named two fields the same and then nested them as an unforced error, a rookie mistake.

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