First, there is a bug in SP1 where on demand triggering data source is not cooking down properly. This means you will have an on demand workflow started per state the monitor can change to so it is adding additional pressure to the runtime. Not sure if we are releasing fix, will look ...

Second, all releases up to date have this behavior, where all workflows related to monitor are started when monitor is registered for the first time. Regular detection workflows may cook-down if they use same data source module (meaning same configuration and such cook-down will possibly fork at some condition that decides what is monitor state). In R2, on demand cooks down data source correctly.

when you are using script as your probe in on demand detection, it gives you additional problem (even if proper cookdown is in place, at least two instances of script will run per instance and race to try to be the first to make a state change). This is actually a good test to see if your cookdown is working, have script raise an event for single instance case and count how many events you have.

but overall, you are correct, on demand gives you some burden, not sure if we are changing much in this space but I can surely try to file some work items for tracking. I guess we did not have much negative feedback which could be caused by the fact that even MS management packs are not using on demand detection a lot ...

I hope to communicate this clearly, cookdown is rather complex problem and I'm not sure if I can explain well as english is my second language (and as our MVP personnels could prove, I like to use a white board a lot in such cases :))

Cookdown is based on the hash that is calculated from configuration sent to the starting module (data source) as XML string, module type etc.

This means that as long as variable value is not present in configuration, there is a big chance for cookdown to happen as expected by the author.

The difference between regular detection and on demand detection in your case is "hidden" in the internal module we use to start on demand detection workflow. It is data source (although not visible thru MP) but unfortunately this data source takes instance ID (equal to target instance id) as one part of configuration. That makes cookdown happen within target but not accros all managed entity -> configuration is unique per instance. Your regular detection seems to avoid such troubles as appears having NO dynamic (or otherwise instance dependent values) present in configuration for data source nor for following probe module.

does it make sense what I just said?

yes, I' saying that you do not have much control on how cookdown will be perfromed because on demand detection uses data source module (start module for on demand detection workflow) which is not cooked down accross entity but only for instance (where entity is a type and instance is instance of such type). So regardless that your "trigger only" probe is cooked down (or would be cooked down), fork happenned already with data source module which preceds this module in your monitor definition.

having multi instance scenario, there might be cases I would try to avoid on demand detection. Such cases would include script base probe (where script is not instance dependant but could for example just read computer registry etc) because such script will be executed for each instance ...