Monitoring service states via the bus is hard, and needs documentation

Hi,
this is about the issue #570. I can't reopen this issue, but please feel free to close this as a duplicate and answer it on #570.

I am also trying to monitor the state of systemd units (more specifically: monitoring when a specific service starts or stops). Because there are no (or not always) PropertiesChanged signals when a service starts or stops, in #570 it is proposed to listen to "UnitNew"-events to then query the ActiveState property.
This could cause endless UnitNew events, because querying a units properties loads the unit, thus triggering a UnitNew event. In https://github.com/systemd/systemd/issues/570#issuecomment-125334529 @poettering suggests to ignore the UnitNew events while querying the properties.
And indeed I was able to get this working with something like this:

def on_unit_loaded():
  remove_signal_receiver()
  active_state = get_active_state()
  add_signal_receiver()

What I find unsatifying about this is that if there are two monitors running, this again results in an endless loop, because the two monitors will take turns in querying the property and thus trigger a UnitNew event, which is then processed by the other monitor, and so on.

I think this whole problem could be solved if systemd always sent a PropertyChanged signal when a service is started or stopped. I don't know if there are good reasons why you don't do this, but maybe you could reconsider it.

Start by reading issue #570 and its linked discussion, especially the comment proposing that UnitNew events be ignored while querying properties. Review how the issue describes UnitNew and PropertiesChanged interactions, then determine whether the monitoring guidance should document a stable approach or clarify the proposed behavior change.