How many people are using OSC for automation, and/or persistence (store/recall)?

I'm trying to establish a standard for automation of my own library of modules (abstractions). Note that I have no plans at the moment for using OSC for network remote control. I only want to use the OSC hierarchical way of addressing components, like

/Instrument/Component/SubComponent/Parameter

But once this is done, network control is easy.

Basic Address Space questions

Like, let's say I have an instrument called Screech. Inside, there are 4 MultiOsc modules 1-4. Each MultiOsc has several things which can be set, like Sine, Saw, PWM, Noise, etc.

So does it make sense to have my address space look like this:

/Screech/MultiOsc*/Sine = 0.5 # sets this parameter in all instances
/Screech/MultiOsc1/Freq = 110
/Screech/MultiOsc2/Freq = 220
/Screech/MultiOsc3/Freq = 440
/Screech/MultiOsc4/Freq = 0

...etc...

Or should I make each instance of MultiOsc addressable like this:

/Screech/MultiOsc/*/Sine = 0.5
/Screech/MultiOsc/1/Freq = 110
/Screech/MultiOsc/2/Freq = 220
/Screech/MultiOsc/3/Freq = 440

OSC for Persistance (SAVE/RECALL of patch settings)

One thing that frustrates me is when I build a large and wonderful patch, and find some settings I like, when I exit PD all those settings are lost.

My style of building instruments is to build patches from a library of small modules (abstractions) as building blocks which I string together to make high-level instruments.

(I am only stating this because I notice that some people build instruments from the basic elements each time)

I want to develop a library of abstractions which have persistence built in, so that when I build an instrument with these abstractions, Save/Recall is also built in.

I am trying to imagine how this would work....???

My idea is that after I assemble a patch built with my OSC-enabled abstractions, I can issue a global command like:

/Screech/CONTROL/Show

This command would be routed to instrument Screech, to a special management module called CONTROL which would query each OSC-enabled abstraction within the patch and say "Tell me your present state".

Each OSC-enabled abstraction which would receive a /Show command, and query the state of every OSC-setable parameter, and report back (how?).

Management module CONTROL then can take these settings and write to a file, which can then be recalled....

I really don't know what I'm doing here, just thinking out loud.

Has anyone already done anything like this??

GOAL=PD Interoperability Standard

My ultimate goal is to develop an interoperability standard for
OSC-enabled PD modules which can then be shared, which have both automation (remote control) and persistence (store/recall) integrated.

Anyway-- I'm quite new to OSC... So I would love to hear/see some *high-level* descriptions of how people are using OSC with PD (block diagrams, or design documents), and/or your general thoughts about how to create a library of abstractions which have built-in Automation and Persistence using OSC, and how these might be addressed in a higher level patch.

THANKS!

--
May you, and all beings
be happy and free from suffering :)
-- ancient Buddhist Prayer (Metta)