> Correct, they don't need to, but they couldn't anyway, as import cycles are not allowed. Package dependencies need to form an acyclic graph.

I was working with those dependencies in mind:

    foo -> {fmt, numbers}  // defines foo.Hex
    bar -> foo             // impl. foo.Hex (T)
    baz -> foo             // impl. foo.Hex (T)
    main -> {bar, baz}     // conflict detected

But now I understand that you declare Hex in both bar and baz independently of foo. The reason I wrote about a global namespace is because bar.Hex and baz.Hex are implicitly implementing foo.Hex thanks to their names (and signature), whereas in other languages foo.Hex, bar.Hex and baz.Hex would be considered as distinct methods. But the confusion is cleared now, thanks.

The example with temperatures is interesting because defining conversion methods is a recurrent problem and you missed one case that is useful too. The European author of the Celsius package doesn't know about Farenheit, or simply doesn't care about it. However, the author of the america package knows about Celsius and needs to convert between Celsius and Farenheit. He could define a ToF method which converts from °C to °F:

    func (c Celsius) ToF() Farenheit { ... }

The same could be done with other units: Rankine, Delisle, Newton, ... (thanks Wikipedia)

Now in Go, you don't declare methods like this. You have most likely:

    func KtoF (k Kelvin)  Farenheit { ... }
    func CtoF (c Celsius) Farenheit { ... }
    func RtoF (r Rankine) Farenheit { ... }
    func DtoF (d Delisle) Farenheit { ... }
    func NtoF (n Newton)  Farenheit { ... }

... each of them called from a manual dispatch:

    func ToF (i interface{}) Kelvin { switch i.(type) ... }

Embedding seems difficult when you don't own the data (e.g. a library creates a whole graph of nodes made of its own types).