I have noticed that, in addition to what I have expressed, a few other Commentators are going to the thought of a top level use case choice input by the resident.
There was the skinning option, and then mine and another's use case selection schemas.
You know, the first few orbital missions of the united States' Space Transportation System were conducted under a configuaration in which the Flight Computer had only 4kb of RAM. The microwave radio modem was pretty warm most of the time, loading and unloding small modules and data sets sent from the surface of the earth.
I just note this, as, with the advent of cheap memory, and huge PC real estate, the trend toward monolithic coding has created bloat. Developers are not so constrained nowadays with a tiny footprint on RAM. There are acres of memory that can be used to store these huge applications.
I have not really considered this to be advancement of the state of the art. In the days of real microcomputing, it was absolutely essential to have only active program routines in RAM, the rest sitting on peripheral volumes and loaded, as needed, and craftily hidden and nexted in branches and loops where a user input, or a screen wipe or screen change would involve the user for the tiny delay whiile a needed module loaded in.
So, with a Second Life Viewer design, we see a similar premium in real estate and resources on the client side, and it seems proper small system application modularity would help both efficiency and correctness, enabling simpler QA proceedures through easily proveable modular structure.
The danger in this approach though is in team forming. It must be around features or options of the whole UI and not the modules. Organizing on modular teams compartments the flow of development information far too much.