Another aspect of the issue is to consider the asymmetric nature of knowledge of the API author and the API consumer.
When one authors a type in a language like C# they must predict how that type will be used and what interfaces the author promises the type can be.
The API consumer might be unfamiliar with the types in an API at first, but ultimately they will know more about how they want to use the type and what additional contracts they think the type fulfills.
As it is, this knowledge is only useful when inheriting a type. There is no facility to "vouch" for a type in C#, currently. In Go structural typing fulfills this.
I think Extension Interfaces is the best of both worlds.
When one authors a type in a language like C# they must predict how that type will be used and what interfaces the author promises the type can be.
The API consumer might be unfamiliar with the types in an API at first, but ultimately they will know more about how they want to use the type and what additional contracts they think the type fulfills.
As it is, this knowledge is only useful when inheriting a type. There is no facility to "vouch" for a type in C#, currently. In Go structural typing fulfills this.
I think Extension Interfaces is the best of both worlds.