Although we can't flat-out drop existing features anymore, we can certain evolve best practices, and introduce more robust features while deprecating and discouraging use of misfeatures over time. This isn't ideal, since getting from deprecation to actually dropping support takes a long time, and in the meantime the possibility of someone relying on features that negatively impact the usability of the language still lingers, but it can still steer the community forward. I for one would love to see a more Haskell- or Python-ish import model, along with the IDE support to automatically groom explicit import lists; @codafi had pitched this before on the old swift-evolution mailing list.
Just to mention that it's not the SSWG's mission to design software by committee. As per the SSWG charter everybody can pitch a library to the SSWG, existing, or new. Assuming it has been proposed, whether a piece of software is listed as 'SSWG approved' is determined by whether if fulfils the minimum requirements. The SSWG explicitly allows duplication and competition.
What the SSWG tries to achieve is to give you certain guarantees about liveliness (e.g. a project will get security fixes) and compatibility (it should work with the vast majority other Swift and for sure other SSWG packages) of a project.
The initial reason for the SSWG reboot was that we essentially had three larger ecosystems in the web frameworks (Vapor, Kitura, and Perfect) with very little sharing. The parties involved however all liked to have more sharing alongside to reduce duplication of efforts. But we also needed some reassurances that a certain packages has certain code quality, compatibility, and complies with other ecosystem standards.