Well, it looks that both me and Alex have prepared something for this, but we have taken different approaches.
Alex passes a preference for switching more/less within the schema and makes the expanding adjusters conditional to that preference,
https://github.com/radmanovi4/prefsEditors/blob/gpii-271/src/pmt/pmtSchemas.js#L254-L256
While, i use an internal-to-the-component model value as a reusable grade,
https://github.com/chrispetsos/prefsEditors/blob/adjusters-pilots-2/src/shared/adjusters/js/expandingAdjusters.js
and a use of it here,
https://github.com/chrispetsos/prefsEditors/blob/adjusters-pilots-2/src/shared/adjusters/js/increaseSizePMT.js 

The way i see it, both approaches have some pros/cons. Alex's approach mandates that you "pollute" the schema with information which is irrelevant to the preferences server, thus creating a need for some kind of filtering before sending to the server for all the "more/less" preferences. My approach has the drawback that one will need to override an invoker for the "more/less" visibility to be bound to an actual model/schema value; and perhaps also the fact that integrator will need to provide some duplicate stuff in the protoTree since it does not merge.

Which approach would you suggest we follow?