/cc @FiloSottile

I don't think this is a bug that requires a code fix. I do agree that the behavior could be clearer though, so changed this issue to a documentation improvement (which I'll send a PR for shortly).

This behaves very similarly to x509.Certificate.ExtraExtensions and I think those docs explain this behavior a bit better:

// Extensions contains raw X.509 extensions. When parsing certificates,
// this can be used to extract non-critical extensions that are not
// parsed by this package. When marshaling certificates, the Extensions
// field is ignored, see ExtraExtensions.
Extensions []pkix.Extension

// ExtraExtensions contains extensions to be copied, raw, into any
// marshaled certificates. Values override any extensions that would
// otherwise be produced based on the other fields. The ExtraExtensions
// field is not populated when parsing certificates, see Extensions.
ExtraExtensions []pkix.Extension

This is the important part of the pkix.Name docs that could be expanded:

When parsing, all elements are stored in Names and non-standard elements can be extracted from there. When marshaling, elements in ExtraNames are appended and override other values with the same OID.

So what's happening here is that ExtraNames will override any standard elements (like Locality or Country) with the same OID. But for OIDs which aren't standard (like the one in your example {1, 2, 3, 4}, the attribute is simply put into name.Names.
If you inspect pkix.Name.Names you'll see that data is still there, it's just that pkix.Name.String() doesn't print these non-standard fields.

Change https://golang.org/cl/229864 mentions this issue: crypto/x509/pkix: clarify docs for pkix.Name fields.