If I may , now that the Win8.1SE project is "mature" and working well, you (we, everyone) are confronted with the old - still the same - issues, that have been faced (and went mostly unresolved) on every PE building project ever attempted.
There is not a "common" use of a PE.
The two extremes are:
1) my personal view: a small temporary OS, the smallest the better, the simpler the better, used to recover/fix a failed system
2) wimb's view (I take him as an example as he is a much respected developer and usually knows where his towel is, but he is not the only one thinking like that): a full replacement for an installed OS, including ALL the bells and whistles (and sound and high graphic resolution and what not)
Of course between these extremes there are any number of peeps thinking that a vital requirement for a PE is a nice background (or a graphical change in the bootscreen) and others that want instead a "bare" system, but capable of running (senseless) .Net applications they use, etc. etc.
Both "extreme" points of view are IMHO to be respected, and as well all the ones between them .
IMHO the only possible solution to have all kind of "customers" satisfied is modularity AND simple ways to access it.
One suggestion maybe to have four "presets":
that already would create four "bases" more modular along the choices/preferences of different users (and different expectations from the build).
But since you are now talking of separating the programs from the .wim (which is good), I would like to propose (again) an approach that has been attempted in the past but that never went "mainstream", using one (or more) separate disk images mounted on the "main" filesystem as directory mountpoints.
Imagine that you have a "core" PE and a completely separated disk image that you mount through any of the available drivers, let's say IMDISK for simplicity, to a directory in the "main" filesystem, say X:\PortableApps.
It would be trifling to make a separate batch, winbuilder script or *whatever* capable of creating a PSTART (or similar) menu based on the contents of such a directory "dynamically" (at boot).
Such an approach would reduce the size of the "core" (allowing better use of RAM, when and if RAM is used for booting), faster booting times (as an example for LAN/Pxe booting), one could also have the possibility to connect to an image containing a smaller set of programs or to connect to a more featured one.
Of course such an approach won't be useful for *all* programs, but I am pretty sure that it may make the thingy more flexible and save a lot of re-builds.