This isn't actually "magic", and as far as I'm aware there is no specific name for it. It is the default behavior of interface implementation.
The core issue of your question is not that there is an explicit "duck typing like" feature that enables this behavior. The core issue is that you misunderstand what an interface contract stipulates and expects from any type that implements it.
public class MyWindow : Window, IMyWindow
// ShowDialog is "magically" implemented by Window
The fact that you call it "magic" suggests that you expect an interface contract to require that this class must explicitly implement a certain method, but that is not the case.
A similar but slightly simpler example:
public interface ITest
public class Test : ITest
The compiler does not complain. Because every class inherently inherits from
object already has a
string ToString() method, the
Test class satisfies the interface contract because
Test has a
string ToString() method.
It's a fairly common misunderstanding of inheritance, where developers think of a derived class and its base class as if they are two separate elements of "the full package". But that is not the case.
For all intents and purposes, when considering the derived class, the features that are defined in the base class are equal in every way to the features that are defined in the derived class itself. The derived class would work exactly the same way if you were to copy/paste the base class' definition inside of the derived class' definition (instead of using inheritance).
Think of it as a "one way partial classes". Two partial classes operate exactly as if they were a single class definition - there is no difference between the two whatsoever (other than the ability to spread it over multiple files). For the inheritance example, I call it "one way" because the derived class includes the base class, but the base class does not include the derived class.
From a comment you made:
System.Windows.Window does not know anything about my interface - from its point of view, the method declared in my interface just happens to coincide with one of its methods.
But you're not expecting
System.Windows.Window to implement your interface - which is why your expectation is irrelevant.
All you are doing is expecting
MyWindow to implement the
IWindow interface, whose contract can be summarized as "must have a
bool? ShowDialog() method".
MyWindow does in fact have a
bool? ShowDialog() method. Whether it explicitly defines its own
bool? ShowDialog() method or inherits one is absolutely irrelevant. The compiler doesn't care about the source of the method, only that it exists.
Therefore the contract (
MyWindow : IMyWindow) is satisfied, and thus no error is encountered.
As a very simple (and somewhat oversimplified) analogy: when I want to buy a $5 drink, does the shopkeeper care where the money comes from? E.g. I could be paying from my inheritance, I could've earned the money myself, I could've borrowed it from a friend.
The shop keeper doesn't care where the money comes from. All the shopkeeper cares about is that I have $5 to pay for the drink.