It's certainly a related problem: with Go-style implicit interfaces, neither a person nor a machine really has the context to know if something that conforms to the interface is actually intended to be used that way, or if it just happens to have the same method signatures. As you say, getName() is a pretty common sort of method name that could mean a bunch of different things, and not everything with a getName() method is necessarily interchangeable with everything else. Explicit interfaces require more work by the programmer, but make those intentions explicit to both other programmers and to automated tools.

In Gosu, we already have Java-style explicit interfaces, but we're likely going to add in Go-style implicit interfaces as a language option as well, since they're not completely interchangeable. The more I think about it, the more I think that you often want implicit interfaces for method arguments, and explicit interfaces for return values. That's oversimplifying, but as a library author you often want to say "this method works with anything that has foo() and bar() on it," so you want an implicit interface so people can use your library with existing code without changing that code to add explicit interface declarations. But if you're providing objects back as the result of a function, you might want to be more explicit and make harder guarantees about exactly what sorts of things they return.