I don't think your far off from my perspective. My consolidation goal is based on libraries that are common across all apps canbe consolidated into dspace-api. And it is better to "extract" the providers of services (Search, Browse, Discovery, Stats, MediaFilters, Consumers, DAO, etc) out of and make them dependent on dspace-api
dspace-common was going to be the project that assembled all these dependencies back together so that you did not need to add them all to each and every webapp.
(Note at one time, I was trying to make the actual dspace assembly project this common maven project, but its difficult to combine assembly and jar projects into one unit).
The reason dspace-stats still is outside is just the dspace-stats is not as as cleanly separated into service and provider as dspace-discovery is. It needs to be separated apart into stats service and stats solr provider to keep the solr parts out of dspace-api (if that is even an issue).
Even if you and I agree is our long term goal to break apart dspace-api into content/core and separate apps, the rest of the committers group isn't fully buying into it, there is not general trend emerging to separate these out (unless theres some big project over in RichardR's space I'm not aware of, but thats another story). This is why I started folding everything together again,
For instance, if we want to replace DSQuery and Browse with Discovery, I think it important that we get the code organized into one project and do it there. This either means that we would alter XMLUI and JSPUI code to dormally remove Search/Browse in favor of Discovery, or we will reimplement DSQuery and Browse as services that reuse the Solr/Discovery Provider.