Comment 1:

True enough, thanks. Not much we can do about that, but at least it's harder to do
accidentally.

Status changed to Unfortunate.

Comment 2:

This seems weird to me. Spec says that only when x.f is a legal selector would the field
or method f be promoted. Since the method is not exported, the selector is not legal and
the method should not be promoted.

Comment 3 by KevinCathcart:

Daniel:
"A field or method f of an anonymous field in a struct x is called promoted if x.f is a
legal selector that denotes that field or method f."
That defines promotion, but it does not say anything about whether a field gets promoted
or not. It only says if the selector lookup rules result in choosing the same same field
or method as in the nested struct, then we call that field/method  promoted. It is a
passive definition.
The rest of that section states the additional rules for determining the method set of
the outer struct. It relies on the selector lookup rules working in conjunction with the
passive promotion definition to ensure method in the method set has a unique name.
One can reach two consistent states from this. One is assuming that "x.f" is an illegal
selector if f is non-exported, and is from a different package.
That conclusion is problematic, because the spec never actually says that. Indeed, the
only prohibitions in the spec on using non-exported identifiers from another package,
are that:
a) they cannot be referenced as a qualified identifier, and
b) that struct literals cannot initialize the value of non-exported fields. 
The other option is for "x.f" to be interpreted abstractly. In that case, the f could be
an non-exported method from some other package without any issue. One cannot refer to
such a method in the concrete syntax, due to the identifier uniqueness rules, but that
would permit the method being promoted. As far as I can tell, that is exactly the
interpretation used by the compiler.
I spent a long time thinking through these things prior to reporting this.