Same with KLV-airedale developments; first the developer will install and manually tweak (maybe via chroot to the KLV root filesystem from host build system) and only when satisfied all is good (which might take a long time) finish modifying the main build script(s) appropriately to allow build-time duplication. Admittedly, all mods could theoretically be implemented in build scripts from the start, but that would be terribly inefficient (including in CPU resource usage) since if not working the build scripts themselves would need hacked and constantly rebuilt. Nevertheless, can still release interim isos that other users can experiment with and make suggestions for improvement including bug-fixes to the running distro - Edinburgh wasn't built in a day.
In my own current KLV-related development (alternative desktop manager) I'm not even releasing anything quite yet since I prefer most of the system to be in workable state before looking for bug-reports/feedback and certainly a while till build scripts updated to include everything I'm experimenting with. I have personally requested current KLV build script from rockedge, knowing it will not be in same state as iso-build at this stage, but only because a partially finished build script is okay for my own current alternative desktop dev needs. I only need his current iso release otherwise for general KLV testing/feedback.
It's perfectly understandable therefore that only an iso of VoidPup32 is available at this stage though of course it will be educational to see the final build script details to see how everything was successfully made to work. No point 'github-style' pushing till you are ready and sometimes it is 'difficult' to implement some work into easily reproducable build script form (not easy to script all human hacking actions, so takes a big effort to do so...).
Mind you, the earlier Puppies did not get published with any build scripts at all. Hence the interest people had in remastering (aside from the fact that remastering is an easier method to modify an original than to modify any build script system and particularly any hugely complicated one).
Also, often, to quote yet another cliche, too many cooks can spoil the broth - it is easy to pick holes in another persons work, which is not very helpful if not done constructively, and different people have different viewpoints anyway - best to hack early versions together in your own quiet time with general feedback taken into consideration...