Extending supervisor functionality: updating child restart parameters and publishing events

While working with Supervisors, I keep running into two pieces of functionality that are not supported: updating the restart parameters of child processes and subscribing to supervision events. I’m probably missing constraints that need to be met by supervisors, possibly performance, reliability or simplicity related. Could someone shed some light on the design considerations of supervisors so I can see what the impact would be of adding this functionality?
Below, I’ll illustrate where I think the additional functionality would be useful.

Updating child restart parameters
The state of some processes will be updated by users of the system, and losing that changed state could mean the system as a whole does not function correctly. In stead of keeping a copy of the state in another process (as proposed by Dave Thomas in Programming Elixir) and having the child process recover the state of its predecessor, you could update the parameters stored in the supervisor that are used to start the replacement process.

In practice, this would mean adding a function to the supervisor that directly updates the children field of the supervisor struct. You could limit this to only allow children to update their own restart parameters. By adding this functionality, the newly started child would start with the correct state, without having to rely on an external service to recover state from. Are there any drawbacks to this approach?

Subscribing to supervision events
When processes are dependent on each other, we can monitor them to be informed of their untimely demise. This, however, only tells you the process is gone, not which process replaced it (if any). Supervisors have this knowledge, and could inform other processes what happened. This would be especially useful when a lot of other processes rely on that process being around. :syn (a distributed process registry) supports something that is similar, but only reports on process crashes, as it won’t know either which process replaced the crashed one. Have others attempted to publish these events in their supervisors, or is there something wrong with this approach that I’m not seeing?