1) Share does not have sub-sites. Strongly related sites, such as all of those run by the Financial Services Division, are tied together by some artificial, unenforceable, funky naming scheme, such as a name prefix – fsd_students, fsd_bookstore, fsd_whathaveyou. Considering that those sites should also be further partitioned in larger areas, and the funkiness just gets worse.
2) The Share interface does not out-of-the-box support delegated rights for creating or naming of sites. Consequently, anybody can name a site anything, perhaps colliding with the use of a different business unit. Namespace management then also requires that you get the name right the first time.
3) A typical use for a Share site is a working committee, such as College of Law Student Retention Committee. We have, perhaps a thousand such working committees. So, our naming convention would be that col_studretention is the site name. Over in the College of Education, someone creates coe_studentretention. The Department of Anatomy has its committee for retention, because of recent retirement of a well-loved professor (fictional), so it would be com_doa_studretention. And on and on and on, for thousands of committees, task forces, projects, working groups, etc.
How well does Alfresco fare with thousands and thousands of top level spaces? Not very well, performance starts sucking after a bit. That is why file hierarchies get introduced. Namespace management is only one of the reasons.
Multi-tenant is not an answer either. It partitions the problem but in the wrong way.
My suggestions are:
o Nesting of Share sites, with a hierarchy of permissions within the site hierarchy.
o Name space management, perhaps by adding policies to how site names may be added and by whom.