Many of the SDK classes that are split between base and mixin are an unfortunate result of the restrictions on mixins that will hopefully be relaxed at some point. My understanding is that the core lib developers did wish they could have had a single class to use as an interface, base class and mixing, and things like IterableMixin are just a work around. I don't have a specific use-case in mind, just the principle that if easy enough classes should be usable as mixins.

I don't think that exposing a `delegate` getter should be considered a leaky abstraction either, in Dart at least. In Java this would be a protected method and I don't think there would be any debate. Guava's Forwarding collections use a protected delegate() method. In Dart we don't have protected, but rather than try to achieve the same visibility, I think we should lean towards allowing fields to be visible on instances, especially if they're not present in the interface that the instance will commonly be referred to.

FInally, I think that these classes are more useful even as base classes when the delegate isn't final. One of the features of delegating is that with the indirection you can give away a reference to the delegator while swapping out the delegate without holders of the delegator knowing. That isn't possible with the constructor approach.