Up to Go 1.13, embedded interfaces could not have overlapping methods. The corresponding go/types implementation, when computing method sets of interfaces, reused the original methods in embedding methods. For instance, given:

type A interface {
   m()
}

type B interface {
   A
}

the go/types method Func Object for m in B was the same as in A. We know that some (external) tests depended on this property. A consequence of this is that the source position of B.m is the same as the one of A.m; it is not the position of the embedded A in B.

With Go 1.14, embedded interfaces may overlap. The same method m (with identical signature), may be embedded in an interface through multiple embedded interfaces:

type C interface {
   A
   A2  // A2 also defines m()
   A3  // A3 also defines m()
}

Now, it is not clear which "original" method m should be used in the method set for C. It could be the "first" one (as in the one embedded via the earliest embedded interface providing m in the source, so A in this example), or it could be undefined. Or it could be a new method Func Object. Note that the latter choice wouldn't be of much help when deciding which position should be assigned to m as it could be any of the embedded interfaces that provide m.

This boils down to what kind of API guarantee should be provided by go/types.