Re: CIM_InstIndication

I agree it would be nice if Pegasus was a full database instead of just a repository, and did things like handle queries, static instance and class indications, etc.
But it is not, and that would be way beyond the CIM definition.
With CIM, there is no need for indications on class creation or static instances, because they don't change as far as the repository is concerned.
With CIM, classes and static instances are created statically with mof files, and have no need for any dynamic provider such as lifecycle indications.
If some one wants dynamically create or destroy classes or static instances, they are probably doing something wrong.

As for your CMS_Module being a Method Provider, yes it should probably also be an indication and instance provider.
If you want to trigger an indication when an instance property is modified, only your instance provider would know.
And you need to create your own data persistence. 
Persistence should not be achieved by assuming code will stay in memory.  There are lots of reasons why that can't be assumed.
And there is no dynamic instance storage other then what you create yourself in your provider, outside of the repository.
The only static instance storage is for static instances that are created in mof files, and essentially it is the mof file that provides the persistence for that.

There may be exceptions to what I have written, but basically if you think of the repository as a database, where objects are dynamically added to it, you are thinking of it wrong.
The repository basically is supposed to just facilitate connections between the clients and the appropriate providers.
And the providers have total responsibility for actual storage and persistence.
If you want to understand the original model, think of CIM as a layer of abstraction above many real remote databases, where the repository is emulating a single hyperdatabase combining all of them. ; Since each real database underneath would have difference syntax and API calls, you would need code to make up the differences.  And that is what the providers originally were for.  And then you can see why the repository should not act like an actual database itself, because it is only supposed to facilitate a front end over the actual real databases.
If you don't have a real database behind you, then just store your instance data out in a file in something like XML format. And read it back in every time your provider is reloaded into memory.

Things are always changing, so there may be more advice others can give. ; But I doubt the basic concept is still any different than how I described it.