I'll try and get round to scripting the KLU-jam build soonish. I could do so tomorrow in less than an hour(!), but some other stuff to do that I want for rc2 release, as I've outlined in KLU-jam thread. The KLU-jam build method lies somewhere between a build_firstrib_rootfs method and a firstribit (weedogit) method. That's one of the easy aspects of building a FR-based distro, it is conceptually pretty simply so can use alternative methodologies to achieve the same end result.
As you know, @rockedge, the FirstRib 'pseudo-full-install' boot trick provides developers with a very reliable mechanism for instantly/reliably remastering the system. And as an alternative a user can use the provided mount_chroot and umount_chroot scripts to modify the root filesystem from a terminal on some other booted host system. And of course, the majority of features provided by the FR initrd can be altered simply by editing the external w_init text file, and if modules needed to be added inside the skeleton initrd.gz, that can be auto-uncompressed using the provided utility modify_initrd_gz.sh. It all becomes second nature once you've practiced a bit with it all. Weedogit was simply a scripted version of manually using such utility 'tricks'.
Some people get confused if there is more than one way of doing something I suppose, but in practice, once the FirstRib build basics are understood, it becomes pretty natural to do things in whatever way suits a given purpose best. I'm biased of course, but I'd say it was a very easy to use build system - makes a nice hobby and Linux distro learning pursuit - and with very easy/shallow learning curve.
Using firstrib to build a distro really is a bit like using LEGO. That's how I was able to build rc1 of KLU-jam in just one day... and it is almost complete for the purpose I intended it (rc2 will pretty much finish it off) and a separate KLU-jamCE can be made to include whatever singing-all-dancing variant the user wants built on top of base KLU-jam. Making an alternative Wayland/Pipewire variant is pretty much trivial to do also; a day job, though polishing any distro to exactly how you want it can take as long as you need to achieve your personal dream configuration!
So if anyone who wanted to build a distro of their own found other mechanisms too restrictive or difficult, then try FirstRib build system. It is really easy to craft your own distro with it in whatever shape and form you wish - you don't even need to be good at shell scripting - that's not what it is about! Rather, FirstRib is about learning how distros basically hang together, but without needing to become a guru at that or programming - upstream does most of the work for you in the end, be that Ubuntu, or Arch Linux, or Void Linux, or whoever provides the repository of downloadable packages, which generally already include their own necessary configuration anyway. For example, when you first build a system based on XFCE, you don't need to configure XFCE - the package has that already done for you. Later on, through familiarity, of course, you can tweak that to your heart's content, but adding only facilities you want, and hence produce customised efficient distros with full frugal install flexibility. Simple.
Yes, the internals of FR initrd are pretty complex in terms of code logic (but not large in code length). However, there is no need to understand its internal coding at all (just learn how to use its facilities...). The FR initrd/init code is already written (and well tested/maintained), so just like a generic LEGO block that is used as the heart of all FR-based distro creations; that's the key to the build system simplicity, efficiency, and flexibility. Result is very little pain, yet lots of gain, and fast production of reliable, solid, multi-distro-type customised variants. KLU-jam could have been built at any time since Jammy was released, just as quickly as it now has been.
Furthermore, being true Ubuntu root filesystem under the hood, every aspect of it can be kept updated simply via apt (since whole system gets updated via apt, not just the installed applications) so it has several solid years of useful lifetime ahead of it whether or not FR initrd itself receives any further development/improvement. However, FR initrd pretty much does all that is required of it anyway - existing version should work for many years without 'needing' any alteration really (actually older versions still work per their design features too - no reason why they wouldn't). Point is that these distro creations are very solid and stable - users don't need to worry about them going out of date or being difficult or near-impossible to upgrade or maintain or needing a new kernel swapped in (which can be a Puppy huge kernel, but doesn't need to be). Same also applies to KLV-Airedale of course, which uses a different, but also reliable package manager that doesn't just allow update of installed applications, but also keeps whole system up to date. That's the overriding reason that these distros can be relied on as stable by design; because the end result is a full-on upsteam-repo-based root filesystem - nothing pseudo about it, but customised (sometimes Puppy-sized) variants of these upstream distros that allows all the frugal install flexibility and facilities we have come to love (but full multi-user capable too). My view in producing it was: why struggle?
Oh... and because I designed the build system to have a build plugin capability, the end result is that I don't even usually need to do most of the work! Rockedge does most all of that (well - and major contibutions by fredx181 of the DebianDogs) for KLV-Airedale via the plugin he continually adds to!... 
and I benefit from the result and can take the code added and put it into my own FR designs later!!! I do try to help though, particularly with FR initrd related matters.
