Thanks ulfr, but the wiki info has been provided and maintained by others.
On further thought and looking at the code, the SCE design is fairly complex from a code standpoint and quite featured, so will require further thought to weave in a fully modular option. In the early days would have been simple, but even then one reason to turn to the self contained SCE was for performance. I copied in a terminal the contents of a a 2GB mounted SCE with 1215 packages as symlinks with the command in sce-load to another place in RAM, took a little over 2 seconds whether the files existed already or not. Now, loading the SCE from scratch took about 2 minutes, but after that loading an SCE with the same package contents and only the addition of icewm took about 30 seconds. The main time factor is the startup scripts. But if loading 1215 packages was done one extension per package, I am sure performance would suffer with the parsing massive number of individual dep files with their large contents, if that were the only factor which it is not. Each SCE that uses another SCE as a dependency has the list of packages of each dependency SCE contained in it, recursively, for use by sce-update and other functions.
Granted, sce-update will make one large SCE get updated for one little startup script or package update. But the SCE approach is as modular as one wants it to be. Say an SCE named base-libs, one named server, one named python, one gtk2, and one xorg, etc, etc, with each depending on the others so no duplication. Would make updating them take less time the more modulear it is.
Thanks for your questions and ideas, all are taken into consideration and vetted, and most features have been the result of a feature request. Not saying supporting a fully modular usage of the SCE conecpt will never happen, I will think more on it and how it can be done in the framework of the existing structure.