You can use FAT32 alright, at least as long as the .iso does not exceed the 4Gb limit.
But you may want to take a step back and have a look at the issue in perspective.
The Easy2boot is a nice tool that is suitable to make something that would be otherwise a bit complex, but perfectly doable manually, it may happen that people is distracted by the easyness of Easy2boot and loses sight of the actual "features" that are the base of it's functionalities.
- The Linux (kernel/IFS/whatever) allows to access a .iso imaged to a contiguous blocklist as if it was a "normal" partition
- The grub4dos can on-the-fly, through the partnew command, create such a partition entry AND mount it/access it's contents in the early "real mode" part of the booting.
- The grub4dos command partnew can calculate the location and the extents of the blocklist corresponding to a given file from the "outer filesystem" addressing entry.
- Easy2boot provides a structure to automate the above features/behaviours and make them easy to be used.
I know how I should not share these info to people that are not (yet) members of the booting club and know nothing about the secret handshake , but if you think a bit about it, there is no "real" need for an "outer filesystem", that would be used only to contain 1, 2 or a few more (if you are what I call a "Linux collector", people that tend to have several distro's with an overlapping of functionalities around 90% or 95%) "largish files".
If you look at the syntax for partnew, you will notice that it was intended:
grub> help partnew
partnew: partnew [--active] PART TYPE START [LEN]
Create a primary partition at the starting address START with the
length LEN, with the type TYPE. START and LEN are in sector units. If
--active is used, the new partition will be active. START can be a
contiguous file that will be used as the content/data of the new
partition, in which case the LEN parameter is ignored, and TYPE can be
either 0x00 for auto or 0x10 for hidden-auto.
to map to a partition entry a contiguous blocklist and feature #3 above is a (nice, BTW) addition.
So, you could have a USB stick divided in (say) two halves, the first one with a partition (and related filesystem) containing grub4dos and related file and the rest UNpartitioned.
For all it matters you could use a plain text file (let's say a .ini) similar to this:
to take note of the distro's that you dd (contiguously) in the UNpartitioned area, and then use a simple grub4dos batch to read this info and map on-the-fly the chosen blocklist using "START" and "LEN" instead of the filename.
Though the dd built-in grub4dos is (understandably) a bit slowish when compared to the "native" Linux one or corresponding Windows ports, you could use that same .ini to actually dd to the stick the distro's from within grub4dos (or write a Windows batch or Linux bash script to the same effect).
In a VERY simplified way, the .ini above (or something similar) would represent an extremely rough (but effective) filesystem allocation table.
I believe that the result of copying a file to an Ext2/3 in a contiguous file may depend on a zillion factors, size of the file, size of the filesystem, inodes number (whatever they are ), actual driver version, actual tool used to copy the file and command options used in it.
It seems that a t least a few of the good Linux guys are (finally) exiting "denial mode" and start admitting (without in any way doubt of the dogmatic "Ext2/3/4 FS need NOT any form of defragmentation") that in some special, rare, extreme cases may not be such a bad idea to have contiguous filesystem contents.