Another useful functionality would be the use of emulators to automatically record dependencies found between different software elements during actual test runs of the software system. This could be extended to multi-process systems as way as single binaries with libraries & plugins.

Things we would like to see improved on:

Monolithic testing/release/downloads/compiling of very large systems

Frequent plugin breakage that is not necessary for development/algorithms

Ease of third party support – e.g. hardware drivers from third parties for Linux

Refactoring code with without unexpected breakage and gaining increased automated support for code movement ops associated with that.

Another way to think about the issue abstractly:

Programming language definitions & analysis provide lots of detailed ways to name & describe tiny parts of software programs – definitions, statements, the set of accessors for a given data structure definition, etc., the set of users for a given symbol definition… Any of these things that are efficiently described with automated tool analysis can be efficiently described as labeled graphs with a neighborhood structure that reflects the given concerns. This picture is an extreme contrast to the tree graph that is only provided by files & directories on disk. It’s shockingly primitive, in a way, to say that the assembly & distribution processes must all or nothing or based only on the file/directory structure of the source code, slowly evolving for continuity. The evolution of the system & its conformance requirements have a different, richer structure, with lots of internal relationships. Outlying depenencies like plugins/drivers & alpha testers should be stepped/versions with the parts of the system that affect them. Those parts should have names & documentation.