Hmm, I certainly think that most of what you suggest can be done, though I can think of a few potential problems that maybe
would make other solutions more satisfactory.
Using a single GUI to control multiple selectable parameters can certainly be done - almost every control of my Loopa project uses this method. As well as the obvious savings in export file size, it can also make Trigger/ReDraw management somewhat easier, and more economical CPU wise.
The sub-presets idea I think may be workable with some suitable preset switching etc., but I can think of a couple of potential problems...
When a new bank (i.e. "global preset" for your idea) is loaded, only the data for the currently selected preset (i.e. sub-module settings) are normally sent. To refresh the whole synth, you would have to cycle around all of the individual presets, reading each "layer" of parameters one at a time. Not only does this add complexity, but there are potential issues with screen ReDraws and trigger management (preset changes perform a global ReDraw that it is not possible to block). It also has the potential to make the user interface more sluggish
Naturally, any trigger/redraw problems would also apply to preset changing by mouse-over.
Also, there are other things that normally happen at preset changing time - firstly the "global" redraws that I just mentioned - but also resetting of code to stage(0), flushing and re-compilation of the audio path. Some of these it is possible to disable within the preset manager - but there is still a high possibility of provoking big peaks in the CPU usage; possibly enough to glitch the audio momentarily.
There is also the question of VST host compatability - I don't honestly how how much of the VST parameter management is done within the plugin, and how much is done by the host (maybe different for different hosts) The VST spec seems pretty robust to being used in unconventional ways, but there would be no guarantee it would be bug-free when used this way.
However, other ways suggest themselves for allowing sub-presets (it is a useful idea for sure).
I have already made a few things which use custom text files etc to store parameters etc. including array tables. the parsing can be a little greedy if the saved files attempt to be verbose (i.e. easily read by eye) - but for sub-presets where there are inevitably fewer parameter, it need not be too bad. It also has the advantge that as well as sub-presets, you could create sub-banks (e.g. a users custom bank of favourite envelope settings).
I have also used this kind of technique to implement cut/copy/paste parameters between sub-modules within a schematic, and also between whole presets - again passing the values by way of a small text file.
It may seem that I have given this an awful lot of thought in a short time - but in fact it has been on my mind for some time. It just so happens that I have the need for precisely such a system myself just at the moment.
Rather unusually for me, I have finally got around to using Synth
Maker to make a Synth
The twist is that instead of SM's poly signals, I am creating voices using a custom voice manager and mono4. in this way, I have the sketch of an 8 voice poly synth - but recreating the architecture of an analogue polysynth. That is, each voice is a separate unit with free running oscillators (poly voices always reset phase at note on) - and each voice could have totally independent parameters (if desired).
The free running oscillators plus individual voice detuning etc. are making some lovely rich, slowly evolving sounds - but I'd like to experiment with radically different sounds per voice for some pseudo algorithmic effects. Depending on number of notes held and some mode settings, the note->voice assignments can "accidentally" achieve some quite complex patterns - but still in some way dependent on playing style - and I'd really like to exploit this to the full.
And so, just like you, I have a need for operating and storing nested levels of parameters.
I think there are some parts that I have already built that may be useful (text file handlers, cut/paste buffers etc.), so I will see what I can put together by the way of some "toolkit" modules that may serve us both.