Postponing until after 1.99 since (a) patch is for outdated version (b) (most important) changes to this code are dangerous and error-prone.

Patch tested, works fine for me.

The next problem i have is again with grub: Why is it not possible to have "menuentry"s in a embedded config files  (in core.img) ???

I totally didn't expect that this wouldn't be possible. Should have read the last sentence in the docu earlier. It's just that I fail to understand why it's not possible. I wanted to install grub with an embedded config and display a menu "Windows/Linux". Then when I choose linux, use "set root=(linux); configfile grub.cfg" and for windows use a different root. The linux root can't be on a windows drive and vice versa because i run one operating system natively and the other virtual. In the Windows VNative case I use VMWare Player and it will not let Linux Virtual (grub) access sectors on a disk that is in use by Windows. Qemu-kvm which I use for Linux Native doesn't have that "problem" but I actually would rather like to avoid accessing mounted filesystems there as well. Which means either unmounting /boot, booting Windows Virtual, mounting /boot again OR having grub not access the files in /boot in the first place by using an embedded "Windows/Linux" selection menu. Which brings us back to the original question.

if truecrypt bootloader is in MBR then the user explicitely requested us to replace it. So such check is redundant.

I consider this a bug in truecrypt. mbr gap is for usage exclusively by bootloader, not for storing keys. (Having TrueCrypt bootloader there is another story). Also the sector 62 is pretty loved by boot viruses and some malwarelike DRMware (e.g. FlexLM). MBR gap isn't for valuable data but only for system code.
BTW as to necessity of Reed-Solomon: it's necessary exactly because of malwarelike DRMware and misstorage controllers.

Truecrypt System Volume Header gets overwritten when you install grub on the master boot record of a hard disk with windows 7 installed and truecrypt full system disk encryption set up.

With system disk encryption the truecrypt volume header for the "system partition" - i.e. the one that holds C:windows - is written to the last (512 byte-) sector (62) of the "dos compatibility area" after the master boot record of the disk holding the "system partition". (The small 100mb partition in front of the system partition that windows creates as it's boot partition and where files like "bootmgr" reside is not encryptet, the system partition is usually the second of the four partitions defined in the mbr)

Reference: http://www.truecrypt.org/docs/encryption-scheme
-> point 2., 2nd sentence

I believe this would not really be necessary. The core.img produces by grub-mkimage is usually smaller than 61 sectors. It just gets bloated by the grub_reed_solomon_add_redundancy() function in grub-setup.c

My idea is to modify the pc_partition_map_embed() function to not include sector 62 of the disk - at least not if the offset of the first partition is more than 63 sectors (2048 typically) anyway.

I will try to come up with some patch to implement this functionality.

Suggestions, warnings & wishes are welcome.