This is what i've replied in another comment: "The adjusters that are supposed to be hidden according to the "magnifierEnabled" value and "moreLess" state are contained in the parent compositePanel (increaseSize) of magnifierEnabled adjuster panel."
I'll try to be more descriptive... That is, the ".gpiic-magnifier-hidden" and ".gpiic-magnifier-category" elements are not contained in the template of this adjuster which is this,
https://github.com/chrispetsos/prefsEditors/blob/adjusters-pilots-2/src/shared/adjusters/html/onOffSwitchTemplate.html
but in the template of its parent compositePanel, the increaseSize compositePanel, which is this,
https://github.com/chrispetsos/prefsEditors/blob/adjusters-pilots-2/src/shared/adjusters/html/increaseSizeTemplatePMT.html
As far as i can understand, the selectors inside an adjuster only go through the HTML markup of the adjuster itself and this is a good optimization. However, in this scenario the "child" adjuster needs to know about elements within its "parent" panel so selecting those elements needs a different way from the traditional "selectors" approach. I'm not sure how this "function ()" method worked, was going through the Infusion lib code and i realized that there was a point where the selector was checked on whether it is of type "function", so i gave it a try, experimented a bit and came up with this.
In order to understand this schematically, imagine that the structure is a bit like the following:
IncreaseSize contains magnifierEnabled, magnificationLevel, magnifierPosition, magnifierLocationFollows, emphasizeLocation, moreLessSwitch
while,
magnifierEnabled should show/hide magnificationLevel, moreLessSwitch
and 
moreLessSwitch should show/hide magnifierPosition, magnifierLocationFollows, emphasizeLocation.
It would be OK to implement this as interrelated conditional panels if the moreLessSwitch was an actual model/schema preference. In this case it isn't (it's just a switch used for displaying purposes and it does not represent a user's preference in Cloud4all terms) so modeling this as a usual adjuster and assigning it a preference would pollute the schema with information irrelevant to the preferences server. That is why @cindyli and i have decided to implement it as an internal component model value described in a reusable grade (as you've proposed some time ago). However, it looks like things are getting quite complicated with this approach. I'm starting to think that we should accept the burden of "special type" preferences which are not sent to the preferences server and implement everything the straight-forward way of conditional panels (the Alex's approach).
Phewwww... what do you guys think?