+1 for this idea. The module dependencies are turning out to be quite difficult to unravel, if we put our foot down and say that all faces-related/dependent functionality just goes in the faces module this will greatly help to simplify things.
Going back to the faces module, instead of continuing with the org.jboss.seam.jsf and org.jboss.seam.faces package split in Seam 3, I think we should put all the faces classes under org.jboss.seam.faces and use appropriate sub-package names. So in this case, I propose org.jboss.seam.faces.application.SeamApplicationFactory and org.jboss.seam.faces.application.SeamApplication for overriding the default Application impl. We will also need the org.jboss.seam.el package (perhaps module).
I think it's just a matter of zooming out to look at the bigger picture when things seem like they are in a twist.
Instead of thinking of replacing the class 1-for-1, think if perhaps there is base functionality that would be relevant for any environment and specific functionality for a framework like JSF. Then, you can create a generic class and then specialize it using a deployment type and @Specializes. Two examples of this so far are StatusMessages/FacesStatusMessages and Expressions/FacesExpressions. I believe that Selector is another candidate for this. There is nothing specific to JSF about a selector, but it just happens to be in the JSF package in Seam 2.1.