> How are interfaces with ability to provide default implementations for members (which both C# and Java allow today) not a substitute for mixins?
Those default-implementations are only accessible when the object is accessed via that interface; i.e. they aren't accessible as members on the object itself. Furthermore, interfaces (still) only declare (and optionally define) vtable members (i.e. only methods, properties, and events - which are all fundamentally just methods), not fields or any kind of non-static state, whereas IMO mixins should have no limitations and should behave the same as though you copied-and-pasted raw code.
> Those default-implementations are only accessible when the object is accessed via that interface; i.e. they aren't accessible as members on the object itself.
That's true in C# but not in Java, so it's not something intrinsic to the notion of an interface.
> Furthermore, interfaces (still) only declare (and optionally define) vtable members (i.e. only methods, properties, and events - which are all fundamentally just methods), not fields or any kind of non-static state
This is true, but IMO largely irrelevant because get/set accessors are a "good enough" substitute for a field. That there is even a distinction between fields and properties in the first place is a language-specific thing; it doesn't exist in e.g. Eiffel.
Making the class add 2 methods and a field for every place the interface would define a field adds noise. And if you have a class with 20 interfaces, that can be a lot of noise. When you consider that the class itself doesn't actually need to know anything about the field because only the interface uses them, it's just... ugly.
That's more of an issue with Java not having properties as first class language feature. In C#, you don't have to deal with fields at all, because auto-properties do all the same things:
Those default-implementations are only accessible when the object is accessed via that interface; i.e. they aren't accessible as members on the object itself. Furthermore, interfaces (still) only declare (and optionally define) vtable members (i.e. only methods, properties, and events - which are all fundamentally just methods), not fields or any kind of non-static state, whereas IMO mixins should have no limitations and should behave the same as though you copied-and-pasted raw code.