Ooh, that’s better than how I was doing this, thanks!
One interesting thing I realized while tinkering around with implementing support for this is that doing so makes the behaviour contract for DynamicSupervisor match that of Supervisor (by returning a list of children + options in init/1).
I agree this behaviour is not common and most apps don’t need such a feature, but it does provide a compelling ‘upgrade path’ from a Supervisor to DynamicSupervisor: just replace the module name in use Supervisor and Supervisor.init, with the knowledge that any callback returns crafted by hand (instead of Supervisor.init) will continue to work since both callbacks now accept the same shape.
Then you could begin converting a Supervisor to a DynamicSupervisor with the knowledge that any children you were relying upon to be started initially in your supervision tree still will be as you gradually refactor how they are launched.
Of course, this is solving a problem I don’t think exists, I just find the parity and parallels pretty—agreed it’s probably not worth complicating the implementation for. 
