Currently we trace logs, which is no more or less overhead than publishing mxuser events. Publishing these instead of tracing log messages, we get two benefits. Firstly, you can write a custom formatter for SystemLog and your job is done in terms of logging. Secondly, you can use the management API to track supervisor status. This is especially useful when you're testing, since instead of waiting some arbitrary delay to hope you've ensured the supervisor under test is in a state that is ready for verification, you can wait to see the management events appear. But this also provides a generalised approach to listening for supervisor events, where you might do things like track restart frequency, count the supervisors in your system, etc etc.
Currently we trace logs, which is no more or less overhead than publishing mxuser events. Publishing these instead of tracing log messages, we get two benefits. Firstly, you can write a custom formatter for SystemLog and your job is done in terms of logging. Secondly, you can use the management API to track supervisor status. This is especially useful when you're testing, since instead of waiting some arbitrary delay to hope you've ensured the supervisor under test is in a state that is ready for verification, you can wait to see the management events appear. But this also provides a generalised approach to listening for supervisor events, where you might do things like track restart frequency, count the supervisors in your system, etc etc.