Personally I'm opposed to anything that doesn't have a really good reason. Once it's in core we can't take it out, so we better be damn sure we got it right.
MX::Types is one thing, it fixes problems with core functionality, but the more code in core the more code can break, the more maintenance burden we have, etc etc. It's already the second generation fix (though there are still a few disputed things about it, e.g. people still complain about the fact that we don't AUTOLOAD class type constraints to delegate to the class, and coring it means we can never change our mind about that without introducing MooseX::Types::ButActuallyRightThisTime). Making dependency haters happy is irrelevant, if you use Moose you can also use MooseX::Foo. They will complain about Moose's deps just the same. So, one by one... StrictConstructor - I'm in favour, but because the code could be used by Moose itself for its even if not with the same API, reducing duplication. NonMoose - i think this is better kept outside of core, it's perfectly fine as it is and allows for more freedoms in the future. Aliases - not yet mature as we discovered today ;-) MultiInitArgs - seems like a somewhat esoteric feature, so no pressing need in core IMHO. Unlike StrictConstructor I can't really imagine myself ever recommending it as a best practice, it seems like a way of dealing with legacy code. SemiAffordanceAccessor and FollowPBP - seems justified due to the simplicity, kinda like the different errors we have, but goes against keeping core minimal. I don't think we'll ever change our minds about these though, because they're so simple and so old by now. Method Attributes - i think this is in the same ballpark as overloading, since we don't support that last I checked (even though it's pretty easy), I don't think that justifies it.
