Well those are a mish-mash of settings (they work but not because they are correct ).
Using DOS disk numbers (0x80), (0x81), (0x82), as you just demonstrated is possible, but since you anyway establish root to a volume (hd2,1) it makes more sense to use everywhere the same naming (hd0), (hd1), (hd2), etc.
Forget for one moment the menu.lst.
When you see the entries, press c to get to command line.
In it (for the USB) type:
It should boot normally.
If it does the entry in menu.lst is:
title WTFPLAY on USB
Same goes for the .vhd, on command line this should work the same:
find --set-root /wtf074.vhd
map --heads = 255 --sectors-per-track = 63 /wtf074.vhd (hd2)
The grub4dos boot command does not have parameters so, on command line you can have:
boot mickey mouse
with the same result.
On a menu.lst entry an implied "boot" command is executed before next "title" or before EOF.
Chainloading more than one sector is "queer", those entries should work just fine with chainloading just the MBR of the iso-hybrid image, i.e.:
There is no need to use winimage to make a .vhd, actually grub4dos interprets a "static" .vhd as a RAW image with an appended sector that is ignored.
The .iso, since it is a iso-hybrid is at the same time a .iso and a RAW image that grub4dos will understand just the same as the .vhd (as long as it is mapped to a "hd-like" virtual device, hd0-31 are hd-like hd32 up are CD-ROM like).
What happens to you should be the following (the grub4dos settings you currently use to boot should be corrected for cleanness, but they are not involved) :
1) when you boot from the USB stick (i.e. from the image directly dd-ed to the USB stick) you are booting from a "real" device, so the Linux system is entilrely loaded in RAM, then upon booting scan for real (hd-like) devices and the EXT2 partition (which very likely is identified by a label or by an UUID) is found, recognized and auto-mounted
2) when you boot from the image (.vhd or RAW .iso) stored on the USB stick, you are mapping it to a "virtual" device, this device only exists in the grub4dos environment (unless you have particular provisions to pass this virtual device info to the Linux) so the OS is loaded in RAM, boots and scan for real devices, does not find the mapped image (which at this point is not available anymore) does not (cannot) mount the EXT2 volume and decides that it has nowhere to store settings.
Usually it is a matter of passing a few parameters to the actual Linux kernel, but it depends greatly on what is included in the distro (in the initrd image) and which parameters it accepts, which scripts are autoexecuted at boot, etc. to find a way to run kpartx/losetup.
Read this thread (seemingly unrelated):
for an overview of the issue and generic (not necessarily good in this case) way to solve it.
In your case - since the Linux OS works already in RAM - you can probably get away with more simply running a script or a set of commands after having booted to mount the EXT2 partition, but it has to be seen.
The first thing you could check should be the differences in mounted devices in the booted Linux between when you boot from the USB stick and when you boot from the image.