Well, as a matter of fact:
1) the MBR of first disk is untouched
2) the MBR of second disk is untouched (and yes, it invokes the GRUB2)
3) the PBR of first volume on first disk (the XP install) is untouched
So the system "as is" is EXACTLY as foolproof as it was before.
Things that may go wrong (though they normally will NOT) :
1) the MBR code of first disk is corrupted -> you can change the disk order and boot to the second disk/Q4OS
2) the PBR code of first volume on first disk is corrupted -> you can change the disk order and boot to the second disk/Q4OS
3) the MBR code of second disk is corrupted -> you won't notice since you are not using it
4) the NTLDR code is corrupted or the file is missing -> you can change the disk order and boot to the second disk/Q4OS
5) the grldr code is corrupted or the file is missing -> you can still boiot to XP or change the disk order and boot to the second disk/Q4OS
6) the menu.lst is corrupted or the file is missing -> no prob we have removed this (theorical and very minor) point of failure
7) the core.img is missing or corrupted or you put another "/boot/grub/i386-pc/core.img" on first disk -> you can still boot to XP (but not to Q4OS)
8) the grub.cfg is missing or corrupted -> you can still boot to XP (but not to Q4OS, in this case you will enter GRUB2 "rescue mode", i.e. GRUB2 command line)
So, items #3 and #6 are not an issue.
Items #1, #2 and 4 are EXACTLY the same as before.
Item #5 is a new possible point of failure (but the consequence will be only partial)
Item #7 and #8 can be further mitigated by having a provision to:
1) identify more exactly the Q4OS volume via UUID
2) by-pass core.img and grub.cfg by having a provision to boot the Q4OS kernel and initrd directly from grub4dos
What is missing, in a catastrophic scenario that WON'T likely happen, is a way to mitigate #1 and #2 consisting in adding to the GRUB2 grub.cfg an entry capable of booting grub4dos, so that you can change disk order and still get to the NTLDR (and consequently) XP.
Since you will need to operate on the "Linux" side, you can safely ignore this, until you will get more familiar with the Linux and GRUB2.
Essentially - however - it revolves around adding where core.img is a copy of grub.exe (and optionally a menu.lst) and add an entry for it in grub.cfg.
Since the good Linux guys decided (stupidly) that it is not a good idea to configure the configuration file you won't edit grub.cfg but rather (I believe) /etc/grub.d/40_custom and "update" GRUB2.
Now that you have learned the "hard way", you can get BOOTICE that includes an editor that allows to modify the embedded menu.lst in grub4dos:
http://reboot.pro/to...-bootice-v1332/
Wonko
.