Isn't duck typing what would let it work without creating that new interface? Do you say it's like duck typing because you don't have to mention anywhere that your two previous interfaces satisfy your new interface?
The interface just defines the methods an object must have to be passed into this function. No types have to "implement" the interface in the traditional sense. Anything that happens to have the same methods as are on the interface may be passed into the method that requires that interface.
Basically, the interface just defines at compile time what Python defines at runtime... except it's a hell of a lot easier to see what methods are required for a Go interface, than it is to see what methods are required for a python function (you basically have to read the entire function and any function that function passes the argument to).
My understanding: In duck typing only the part of the structure/method set accessed is checked at run-time for compatibility, in structural typing everything is checked at compile time (even if those checks follow loose duck-typing rules). To the programer they appear to be the same most of the time.
I'm not the least bit a Go programmer, but it sounds pretty different from a programmer's perspective to me. With duck typing your methods end up with conditional logic based around respond_to calls. With Go it seems like it's declarative. Whether you like that or not, you have to admit it's pretty different for the developer.
You never have to declare what fulfills an interface in Go. The fulfillment is implicit. If you define an interface with the Quack() method, anything with a Quack() method on it can be passed into a function that takes that interface, even if that object has never heard of the interface or the function. You never declare that a type "implements" an interface in the way you do for languages like C++ or Java.
