Now that I am also using WDL_Arch64 as a 'server_for_the_whole_house' via tiger vncserver and VirtualGL (for hardware accelerated graphics done on server) I have basically adopted a three layers approach to its implementation, which consists of 08firstrib_rootfs (folder or sfs), 50upper_changes (folder or sfs), and optional external media non-numbered upper_changes folder.
First layer (08firstrib_rootfs) contains core WDL_Arch64 that I am less likely to regularly change - it contains what I arrange the f_buildplugin to produce during build_firstrib_rootfs distro build.
Then after first boot (with no 50upper_changes made yet), I add new larger or more likely to be upgraded apps, so these new apps go into standard external media upper_changes.
Finally, once I'm satisfied I have all the apps and utilities the whole household generally uses or wants, I rename that upper_changes folder as 50upper_changes (or whatever layer load number I want for it), so basically as a rollback file that could be deleted if I want to get rid of it. Being now thus numbered it will get auto mounted as a read-only layer on next boot.
Then on reboot, I use w_changes=RAM1 (or RAM2) mode, which creates a new (non-numbered) read/write upper_changes folder in RAM so I can choose thereafter, at end of any session whether to save changes (as read/write upper_changes folder) back to disk media or not.
On the rare occasions when I want to upgrade any of these big apps inside 50upper_changes I just delete the external non-numbered upper_media folder (or keep a copy of it modified to retain only config information I can keep there). I then rename 50upper_changes back to simply upper_changes (so will be writable on next boot), reboot, use pacman to upgrade or add whatever I like, and then rename upper_changes back to 50upper_changes per previous description.
Advantage is that actual upper_changes folder isn't actually needed at all or can be kept at tiny size so when using any in-RAM mode loading and persistence saving tends to be very fast indeed and not waste RAM.
Current server is chock full of stuff (mainly because of my demanding kids and for my partner's business running needs) including:
GTK, Qt5, Libreoffice, wps office, cherrytree, Chromium, latest full inkscape, full gimp, blender, kdenlive, masterpdfeditor, nomacs, Okular, tesseract ocr, gimagereader, OCRFeeder, tigervnc server/virtualGL etc, skype, viber, discord, zoom, msoft teams, minetest, supertuxkart racer, and much more... and of course all the usual: openbox/tint2, geany, pcmanfm, wex, Precord, lxterminal, mtpaint, and all the usual Puppy-sized apps along with pretty full-on compiler dev system for compiling and so on with gcc, git, Python3, perl...etc
Special mention for calculator 'Speedcrunch' - for business users much better to have history mechanism provided by Speedcrunch (alternative that is also very good, but too complex for my partner: Qalculate).
Also Okular is amazing for extracting/modifying tables out of pdf files for use in excel/libreoffice or wps spreadsheet) - pity it is HUGE cos uses so many kde libs (I don't use KDE, but found nothing as powerful as okular though 'tabula' is a simpler java-based alternative). Fortunately okular does not result in extra CPU or RAM demands (just storage space) so system not slowed down at all - its speed basically being determined by simple openbox/tint2 as desktop (no way I'd load KDE...) so same kind of resource usage and speed a typical Puppy user would be used to on their equally old hardware (aside from the server I normally install this onto old 2008 core2duo systems and runs like lightning).
Anyway, with that setup I have no need of further messing around loading/unloading sfs modules or portable apps - and accessible to anyone in the house via vncviewer too (though actually have same system copied over onto various computers in the house anyway, but some of these are older machines that can't themselves run OpenGL above version 2.1 so use server to do the accelerated hardware graphics when needed. Overall, proving easy to maintain, which is vitally important since my partner's business depends on its specially configured functionality and I don't myself have time to mess around continually configuring the system trying to get apps/new-apps to work...
Of course I do have 100 module loading layers (as layer-numbered normal folders or as layer-numbered sfs files or any combination of both) available with WeeDogLinux as it stands, and actually do load Puppy apps/portable-apps via one or two of these when wanted, but overall just want everything available and loaded all the time.