> First, it does look it up to acquire its own instance. But for how 
> long one subsystem keeps a reference to a dependency, that depends 
> entirely on the subsystem. One subsystem (ex: publishing)  may wish to 
> get a list of their dependencies and cache them for the publishing 
> subsystem's entire lifecycle.  Another subsystem may wish to 
> re-resolve its dependencies  from the server-behavior class for every 
> single call to ensure it has the most up-to-date version, or create 
> new instances every time via the subsystemModel and extension points.
>
> In short, there is no one "proper" subsystem... because what is proper 
> depends on how long one subsystem intends to reference the other.
>
> As of now, most subsystems resolve their dependency once per instance, 
> and hold onto that reference until their lifecycle is over.  As of 
> now, the only subsystem we have that doesn't disappear immediately is 
> publishing, and in that case, it's appropriate to resolve their deps 
> only once.

This is where I'm completely not grokking how we can ever get reusable 
subsystems if there lifecycle is not well defined and can change at any 
time and there is nothing defined on how these should read/write data. 
If I created another instance of these whatever shared data they put in 
the server data area would have concurrency issues and be close to 
impossible to debug/trace down.

/max