Methods from embedded things can only be promoted when they are unambiguous.
o.Func3 would refer to the embedded struct/interface and the method would be referred to as o.Func3.Func3(),
so it is correct in that o does not satisfy the interface

I get your point but that's still a little confusing. I would argue that o.Func3 is the embedded interface and hence o implements Func3. On the otherhand side, o.Func3() is ambiguous and hence o.Func3 does not implement Func3 anymore although it's type promises exactly that?

It may help to read through the recent discussions about embedding, such as #6977

/cc @griesemer

This is working as expected. A simpler example will make this clearer:

package main

type M interface {
	M()
}

type S struct {
	M
}

func main() {
	var _ M = S{}
}

The type S is a struct that embeds M: This means it has a field, which - by spec rules - is called M. Since that field is embedded, the struct "inherits" M's methods, which happen to be just M. But that method is not visible; it's a level deeper than the field M itself. In short, S doesn't have a method M, it has a field M. When trying to assign an S value S{} to M we get a pretty good compiler error message:

./prog.go:12:6: S.M is a field, not a method
./prog.go:12:6: cannot use S literal (type S) as type M in assignment:
	S does not implement M (missing M method)

Consequently, if we try to see if an empty interface holding an S{} is an M using a type assertion, it will fail, which is what happens in the original example. There's not much the compiler can do here in terms of error messages. It's a perfectly valid type assertion that simply fails.

Changing the method name from M to M1 makes this work: Now the method M1, even though at a level deeper than M, is not shadowed anymore by M.

I agree that this can be confusing. Embedding is one of the most complicated parts of Go. Advice: Don't name methods the same as fields (or in this case, types).

Closing as working as expected.

PS: Just a friendly reminder that it helps to whittle down examples to the bare minimum when filing issues. Often it makes it clear what's wrong and the issue doesn't need to be filed in the first place. And if it is filed, it helps us to get to the core more quickly because we don't have to simplify the example first to see what's going on. Thanks.