for flrn, the basic structure of fig os is this:
* puppy iso is downloaded
* refracta iso is downloaded
* isos are opened
* PUPPY ISOLINUX (.bin, and config) is used
* however, it could have used the refracta isolinux (which it borrows some config lines from and adds to the puppy isolinux config)
* puppy sfs is modified
* refracta /live squashfs (this is the same as sfs) is modified
* iso puts puppy stuff on / of iso, which is how puppy does it anyway
* iso puts the relevant refracta stuff in /live which is where refracta keeps that stuff anyway
* finally, the stuff in / is mostly just puppy stuff. bootloader, config, that stuff doesnt make it from refracta
* that stuff from refracta isnt used, it isnt part of the "hybrid" design
* however, it would be just as easy to use the isolinux stuff from refracta INSTEAD of from puppy.
one reason for using the puppy config was to reuse the puppy boot screen without redoing the configs. one reason to switch to the refracta isolinux instead (and then borrow a few lines from the puppy config) would be to do a png bootscreen like refracta has-- puppy often uses a 16-color (256 color?) lss file, editable with mtpaint.
but to directly answer flrn, the two distros share a single isolinux config. the isolinux config (but not the bootloader) is merged from the two.
with a 32-bit bootloader, you can use this to make a live cd that will boot into a full 32-bit os or a full 64-bit version of the same os, but for example to do that with refracta 32 and refracta 64, youd need to have one with squashfs files in /live and one in /live64, or something like that.
so far ive only tried the 32+64 idea out on a 32-bit puppy and 64-bit refracta, but fig os is 32-bit puppy and 32-bit refracta.
the arrangement would not work if the 64-bit machine could not even load the 32-bit bootloader, but most 64-bit intel/amd machines will. i believe the 32+64 arrangement (with 32-bit bootloader) even works on the 64-bit mode of qemu-- as it should, really.