Hello Pirmin,
I think the crux lies in the combination of init's dynamic reconfiguration with resource saturation. There are multiple culprits.
First, you need to consider that once assigned resources cannot be withdrawn without the consent of the subsystem. During the configuration, components can temporarily disappear, which temporary frees their resources. Now, when using the resource saturation mechanism, those temporarily freed slack resources would end up in this single subsystem. Whether or not you can eventually regain those resources (without killing/restarting the subsystem) depends on the behavior of the subsystem, which is presumably not what you want.
Second, resource peaks can occur during the dynamic reconfiguration in the presence of chain reactions like in your case (the restart of the vfs implies the restart of its clients, transitively...). During the orderly destruction of inter-dependent components, init is required to keep parts of disappeared components around to maintain their resource accounting information until the chain reaction has settled. So it can happen that two instances of the same component exist as an intermediate state - the old one that just turned into some kind invisible zombi, and the freshly started one. If the resources are fully saturated, this usage peak cannot be accommodated.
As the bottom line, resource saturation should only be used for static init configurations.
Regarding your specific problem: Since you are consuming init's state reports already, couldn't you avoid the use of resource saturation by using the reported 'avail_ram' and 'avail_caps' to dynamically assign a sensible amount of resources to the runtime subsystem?
Cheers Norman