Agreed about C# multiple interface handling. I'd really like to see something like that added to Go at some point.

In fact it's probably not that far away from where Go is now. Go already has something very similar for implicit composition / mixins. Now, if you do something like this:

  type Foo struct {
    Bar
  }

Then Foo automatically has the methods of Bar, e.g. Foo.bar() instead of Foo.Bar.bar() although the former is really just shorthand for the latter.

If you then have:

  type Foo struct {
    Bar
    Baz
  }

Then assuming that Baz also has the method bar() then you now need to be explicit about it and call Foo.Bar.bar() or Foo.Baz.bar() because the compiler doesn't know which one Foo.bar() means.

Of course, this is slightly different to interface disambiguation, but there's no reason why you couldn't have two function definitions with the same name and some added interface qualifier - the functions would then only be callable if the object is cast to an interface. In Go, casting to an interface is a bit like boxing, as it creates a separate vtable for that object's methods to match the interface ABI.

Hence, you could have say:

  a := Foo(foo) 
  b := Bar(foo)

Now a has a vtable entry for Foo::foo() -> a.foo() and b has a vtable entry for Bar::foo() -> b.foo().

On the other hand, there would be no foo.foo() method unless one were declared separately without any interface qualifier.