My 2c, based on doing some heavy customization of Allura: Given the robustness of the setuptools-based system, I would see it as beneficial to deployers to have as much choice as possible in selecting tools with real versions on them. This would allow managing their installation via pip, with their configuration in their production.ini. We were bit more than once by just working off production tags (allura_20xxxxxx).
For example: others have already expressed dissatisfaction with the complexity that ForgeSVN introduces at setup time, and an organization that embraces git/hg is unlikely to have svn around except perhaps for legacy codebases and mirrors of external code (though the DVCSs can handle that, too). Of course the challenge, especially with the VCS tools, is the level of hoop jumping that must occur to get all of the content exposed through the SSH host, which has got to be my least favorite part of the exercise: I could see how refactoring this out to be aware in a separate environment would complicate things. I think "small core" would allow focusing on improving infrastructure that differentiates Allura from other more general web frameworks: opt-in elements on Artifact (like comments and voting), generalized diffing, neighborhoods and projects, robust permissions, indexed search, API specifications, async tasks, reusable themed widgets, analytics, asset optimization and other stuff that doesn't work right if everyone does it differently. Further, the version of core would become more meaningful (and stable), which helps give create clarity and common purpose. The unfortunate thing would be the increased brittleness across many tools: who's doing what to magic `c` and magic `g`? This would require some pretty serious automated, matrixed testing of install, operation and migration.
