I agree with hasmak ..... maybe it is an age thing, who knows? ...... but to be capable of creating an ISO of 9GB or more would be advantageous to some, IMO.
The limiting factor is the file size contained within the ISO.
Musings:
There are at least two ways of removing that limitation in practice ...... change the limit in the ISO or break large files into smaller ones. Not going near the ISO spec ..... 
There may be other means also ....
In the case of building a live OS environment, I would think it possible to arrange to mount the various parts or the files system from different files.
Because of the complexity and other possible side effects, I would think this method would not be the most suitable for general use ..... but if it could be developed it would make specialised requirements must easier.
Another idea which might be even more suitable ...... for those specialised situations .... generate a liveUSB without any size limitations like CDs or DVDs ---- a 30GB live OS on a 32GB flash stick anyone? ... no compression needed at all.
Maybe a 'full install' to a USB flash stick, with those items set to do hardware detection on boot and other such things as in a live OS. Dunno if this would be very suitable.
All of that brings me full circle ...... and generates the question ..... is there not a more suitable and practical method of getting a large mobile live OS already in existence, that does not need to come up against the problem of the file size limitation?
..... maybe the cat is already dead and there is no need to avoid scratches when skinning the beast! 
Hi just19
welcome to the discussion
First let me tell you that the cat is not dead

But first things first, the file size limitation of 4GB is set in the ISO file system specifications, that means you can not write a single file larger than 4GB to an optical disk or disk image, hence the need to split the .sqfs file.
Melodie has mentioned clonezilla (or similar applications) I don't think this will work, disk imaging tools usually do a sector by sector backup, that can not be deflated to ram as file system with directories and files, it can only be written back to a disk.
It seem to me that there might be an easier track, mylivecd uses one 3 different compression and archiving applications to produce the .sqfs file, most compression applications can be configured to split the archive at a preset limit, and when you are unpacking the archive you only call on the first part which will call all the other chunks in sequence.
If we can get mylivecd to pass the spliting parameters to the archiving applications then that is half the work done, the other half is examine what happens at boot time, how is the archive unpacked, and what parameters need to be passed if any.
The idea of having mylivecd build a bootable usb device is brilliant and should be considered, however there are 2 downsides, 1- not all machines can boot from usb, and 2 mylivecd was not written with that in mind and may need a complete rewrite. also there are already other tools to do that, I haven't tried that because my current machines do not support it.
Let me know what you think
cheers
PS
I might be out for a while, will try to get back to u ASAP
cheers again