2) Yes, the idea is that a small (small means - provided that you don't want to store in that partition iso's or install OS's some 100 Mb or less, in the case of string a .iso on it, FAT16 no more than 1 Gb (if the needed space is more, switch to FAT32), and in the case of FAT32 let's say whatever is enough to fit the (single) .iso you want to store there + 100 Mb). A small partition means that it can be cloned/saved (and restored) in no time, even on one of those USB sticks that you surely have, forgotten in some drawer because they were too small, and FAT16 is compatible with *anything* and FAT 32 is compatible with anything but very old DOS versions.
4) It is NOT Grub. It is grub4dos. Yes, the generic idea is that *anything* including the grldr and menu.lst (part of the grub4dos package) should ideally be "as early as possible" on a "as early as possible" partition/volume, the code (in the MBR+following sectors) AND the script (embedded in grldr) that later loads menu.lst both "scan" available devices to find first grldr and later menu.lst, so the earlier they are, the faster will be the initial part of booting. Imagine that you have to look for menu.lst on (hd0,0) i.e. first disk firs partition, d@mn it's not there, let me try (hd0,1) first disk, second partition, d@mn it is not there .... and you find it finally on (hd0,17)
6) If it works, leave it as is, no need to change, your setup is so that the MBR AND 17 (if I recall correctly) following sectors at the very beginning of the hard disk are filled with grub4dos booting code. Everything is cool and you will likely have NOT any problem. The issue I raised is/was that while the MBR is (to a certain extent) "sacred land", and programs/tools/OS tend to respect it (mostly) only writing to it "properly" some "proper" data or code, the so called "hidden sectors" (from 1 to 63 on XP and earlier and from 1 to 2048 on Vista and later, usually) are "no man's land", any program may decide to write to them any kind of crap, overwriting the booting code. Of course most programs, like 99% won't do that, and of the remaining 1% one half knows that some bootmanagers occupy more sectors than just the MBR and if they have to use (even temporarily) some of the hidden sectors, they use higher addresses than the first - say - 32, so it's a safe setting , covering 99.5% of cases (completely invented percentage, of course) but not an "as safe as possible one". I have seen people cry when (usually old disk related programs) overwrote sector 12 or 14, but as said nowadays it is a really rare case.
7) Your sintax is "generally OK". It is a "generic" way that works, very suited to (say) a "portable" media, but if you have a "fixed" setup, you may want to "hardcode" the devices and remove the find --set-root command. Just like previously described for grldr and menu.lst the find command will start scanning all disks and partitions until it finds the .iso file, the delay is usually non noticeable, still if you already know that xx.iso is on second partition of first disk (hd0,1) in grub4dos syntax, you can go directly with :
map (hd0,1)/xx.iso (0xFF)
This is a pet peeve of mine, once you know where something is, you don't go looking for it everywhere, you ALREADY know where it is and just get it.
Moreover (and this might become an issue) if you have two .isos or more generally two files looked for by the find command with exactly the same name in the same path (let's assume for simplicity root) of two different partitions you cannot be sure WHICH one has been found (it is possible to find that out as the scan is made in a given order, of course, but you cannot be sure until you have checked).
... you motivated me to go ahead, to try new different ideas that I have...
So Wonko, receive my sincere gratitude for all your great help and explanations.
Good , that was the idea, you are welcome.