I'm not sure I understand your questions. Multiple monitor sessions are
like multiple shell sessions. I don't think a control program should
use more than one session, but it should allow a developer to connect to
issue 'info registers' and 'x/20i' commands. Of course if a developer
issues 'quit' or a hotunplug command, things will break.
We agree if we want decoupled states of the monitor sessions (one
session should definitely not be used to configure the output of another
one). But I see no issues with collecting the events in one session that
happen to be caused by activity in some other session. But maybe I'm
missing your point.
btw, why would a human enable notifications? Note notifications enabled
on the management session will only be displayed there.
It's true that the common use case for events will be monitor
applications. Still, enabling them for testing or simple scripting
should not switch on ugly output mode or complicate the parsing.