That is, support *functional* dependencies between processes,
Well, explicit stated dependencies are there. If you mean something beyond that, I get very concerned.
caching of input/output.
What i/o are you referring to? I/O generally is already cached as intelligently as the filesystem or block subsystem can manage. At filesystem or lower or inside the application are your opportunities to enhance things, not much room in between. If you mean cache data that is piped around or networked around, that is absolutely a horrible idea that is really infeasible unless it's in the application (it is impossible for an infrastructure to ascertain whether cached result is good enough in a generic fashion since it isn't in the middle of the transactions or understanding the flow.
automatic starting of processes when configurations change, etc.
This would be horrible. If it is a process that reads config only at startup, you have no idea of knowing when the changed on-disk copy is 'ready'. You cannot graft magic onto such a daemon. On the fly reconfiguration is already available even in standard libraries if applications want to do that. This is another problem that cannot be reasonably added in a sensible way without cooperation of the managed applications.
Right now, my computer has to reboot whenever stuff changes
Something is very very very wrong in your case. Updates sometimes are more practical to reboot to just be sure that stale copies of vulnerable libraries are surely out (and certain platforms require a reboot to replace open files at all), but no reconfiguration necessitates a reboot short of reconfiguring very particular kernel/driver settings.