That would just move 3 components to another level but they are still needed: scanning existing service directories, diffing between desired and current state and applying - so creating or removing directories.
So, diffing between desired and current state, and applying the modifications are components of a *service manager*, not a supervision suite, and it is important to maintain the distinction in order to avoid scope creep in s6. Even when a service is *not* instanced, these components are somewhat needed; it's just not noticed because their implementation over a single supervised service is trivial. But it is important to remember that the job of a supervision suite is to maintain the service in its current state (up or down), *not* to manage the wanted state or apply it. (Of course, it does provide tools to perform state transitions for longruns, but it comes with no policy on when to call these tools.) The components you want definitely have their place in s6-rc; but in the meantime, they can also be scripted on top of regular s6 if you have a good modelization for implementing instances, which I will add in the near future.
I see there a problem with multiple dynamic services. I'm not sure about concurrency behaviour of updating processes in the service directory. Maybe Laurent can explain problems in that area, if they exist.
s6 manages processes and every supervised process needs its own service directory. There will be as many service directories as they are instances. (Some components of a template service directory can of course be reused.) So there's no concurrency issue; however, the instance management tool I'm thinking of could adopt various updating methods depending on what you want. Best effort? Clean shutdown, service replacement, then firing up of the new service's instances? Rolling upgrade across the instances? These policies all have their uses.
I'm not sure how complex the supervision itself is - however I would love to solve the problem without doing supervision on my own. I thought about your approach as well but it really depends how resilient an update process is.
It will definitely be resilient, but there are several ways to implement
it, see above. -- Laurent