Perhaps we wouldn't give the option for addons to be in a virtual subtree - they always would be, including on git. That would definitely make things less overwhelming to developers. Right now there are a lot of files under sources/.

We could make it an option in the installer whether to have a small number of important addons enabled, or all bundled addons. That way new users can avoid being overwhelmed.

Note that Cloud-FS gives Composr a virtual filesystem for the purpose of cloud deployments, and also shared installs. Perhaps we should look at potentially extending that.
An alternative would be to provide a virtual view via Commandr-FS/WebDAV, although it would not get all the same advantages discussed here.
Yet another potential would be to have a script that allowed creating a big structure of symlinks outside the Composr directory. I actually like this a lot, it takes the overhead out of Composr and just makes this all a developer niceity. Again though, it doesn't have all the advantages described here, but perhaps some of those advantages could be attained in other ways anyway.

This solution would also probably solve the issue of adding overrides to non-bundled addons. Currently, non-bundled addons store all of their code in _custom directories. The only way to effectively override a non-bundled addon is contentious overrides in v11, or just editing the file manually. These solutions might not be ideal in v12 when we introduce #3049 and automatic updating of non-bundled addons .

Thinking this through more...

I agree if we implement sub-tree support, it should *always* be used. There are many issues we might face if we allow switching between the two, especially with permalinks / URL rewriting.

Possible way to go about this is to change the Composr directory structure entirely...

1) In the root of Composr are all the files that were there before... _config.php, .htaccess, index.php, and so on.
2) Every addon (including core) is its own directory immediately under root. And it contains its own Composr structure of lang, comcode, pages, themes (except templates_cached), zone folders, etc. We'll need to discuss if _custom folders would still be necessary because ideally you'd put anything custom in a new addon. At this point, _custom would only override the specific addon's code.
3) Pages / zones / themes / overrides (which apply globally) not created as part of an addon would go under a "custom" directory immediately under root. These files can later be moved into an addon-specific folder when someone uses the export addon tool.
4) Composr would still contain core folders not pertaining to a specific addon, like caches, temp, safe_mode_temp, possibly imports and exports, immediately under root. It would also include uploads as-is because there is no compilation involved with those.
5) Composr would have a new "compiled" folder which compiles together (when needed) everything from all the sub-directories, and does so in a very similar structure to what Composr uses now (minus the custom folders). The exceptions are folders not addon-specific (caches, safe_mode_temp, temp, etc.), themes (except it will contain the cached / compiled templates of each theme), and uploads. This acts as a cache but is also the files which are actually executed / run. Resources are re-compiled when the smart cache thinks something changed in any of the directories. Self-learning cache would aid in tracking maps between files for compilation. A cleanup tool allows the cleanup of these files at any time.

The compiled folder would be git ignored.

This is a super modular way of doing things, but I think it would work out nicely. However, the biggest caveat would be URLs. Since all the pages would now be located under a "compiled" folder, something like adminzone/index.php would no longer work without mod_rewrite. Everything would have to point to the root index.php file for pages, and index.php would have to guide where to go from there.