Say we have a tab with an enable title button. That tab pertains to some kind of functionality that has an optional modulator employed as a conventional LFO. On the tab, we have a button that enables/disables the LFO processing. We might use the processing on the tab without the modulator at times and with it at other times. The tab being active (enabled) does not imply the modulator is needed.
We want the modulator turned off if either the title-enable button or LFO-enable button says “disabled”. So, which of the two enable buttons should turn the modulator on or off? Both cannot without providing either a confusing user experience or leaving the modulator running when it should not be. I could supply a simple MXXX preset that demonstrates this if the above example is not clear.
Here’s a possible way to address this. I don’t believe it would break any existing presets, but maybe I haven’t thought it all the way through. Basically, consider any MP that controls an enabled state (be it the enabled state of a modulator, an MXXX module or even another MP) to be an “enabler object”. That which is enabled/disabled by one or more enabler objects is an “enabled object”. Each enabled object keeps a list of enabled/disabled states, each entry in the list is associated with one of the enabler objects. When an entry in the list changes state, the enabled object checks the full list and sets itself to enabled *only* if all entries in the list indicate enabled.
There is a workaround to this problem if the enabled object is an MXXX module: a trick cleverly devised by jmg8 that embeds the enabled module in a composite module and thus has two levels of “enablement” to play with. But the trick cannot be used on modulators or MPs.
Anyway, maybe this is something that might be considered for the restructuralization effort … any chance?
. Ok, so basically it's not really logical for me what you suggest about that "enabler", it would seem more like a different new subsystem than a multiparameter. Also it's a very very specific case, so creating something for sake of just that seems too much imho.
The problem, however, is considerably more general, IMO.
There's also an option to "Synchronize to LFO" which means the speed of the random modulation will be the same as the rate of the LFO. That is if the speed parameter for the random modulation is set at 0,00 %. At 100 % it would be precisesly double as fast as the rate of the LFO etc. 
