I think the implementation looks like an improvement - I feel like a lot of this implementation is relying on us only considering mixins actually mixins if they only have exactly one construct signature - but I guess for now that's a safe enough assumption to make, seeing as we make it elsewhere. Maybe @ahejlsberg would have a more nuanced opinion about how different constructor visibilities should interact, but combining only all the public ones (while keeping the private signatures in for relationships' sake) seems fine to me. The inheritance of protected construct signatures from mixins might be a little odd in practice, though (I think you'd be able to use a protected mixin constructor signature so long as you're constructing a subtype instance within a subtype of the class you're mixing, which might be weird and way too loose).

@andrewbranch up to you if this should hit the beta/rc pipeline or be held longer/discussed at some point~