I tried
dd if=M32-083.img of=\\?\Device\Harddisk1\Partition0
and it didn't work.

I think you may be onto something though.

In
http://www.xbox-linux.org/wiki/Xbox_USB_Compatibility_List
There is a note
*UPDATE* - A Jetflash 2.0 TS1GJF2B has been successfully used. Used Eraser http://www.heidi.ie/eraser/
to thoroughly format drive.

*EDITED*
I know that some instructions to make a thumbdrive bootable include zeroing the bootsector and many instructions to make a thumbdrive linux bootable include running shred on the thumbdrive. Maybe the thumbdrives have a residual memory problem where your first overwrite doesn't take.

*END EDITED*

I sense there is some Windows residue on our attempts to write bootsectors from Windows, because My Computer (win explorer) reads the thumbdrives as perfectly normal. Even when in the cmd mode we are dependent on windows drivers etc to get to the thumbdrive.
In my Dos imaging attempts, i would try to boot Dos using Dos USB drivers and would get inconsistent recognition of the pendrives.

*EDITED*
I really suspect the behaviour of the controller on the USB key may have something to do with our problems. The CHS info that we are laying out in the bootsector is being passed on to some kind of ramdisk conversion to a sequential address in the flash memory. The M32-084.img is lays out sectors sequential to a floppy with sectors of 512 bytes at a particular CHS location. If the USB controller didn't write the sector in the right CHS then the read at boot time gets garbage. Maybe we might have to tinker with the image to get the right memory map.

It may be the the tools we are using to look at the thumbdrives.
I know nothing about Linux but since i can't get reliable access to the thumbdrives through DOS, l started using SUSE Linux. I don't know any tools but thanks to this post I dd if=/dev/sda/ of=usbpen.img, then i od -h N 200 usbpen.img.
I dd if=/dev/fd0 of=floppy.img and od -h N 200 floppy.img. The two hex dumps did not match. I thought I had put the image of a bootable floppy on the thumbdrive but Linux, while confused about the device capacity 1.4mb vs 1gb, knew the physical parameters of the the thumbdrive (1gb) and used it.
Linux uses the SCSI protocols to access the thumbdrive, and at the SCSI level the motherboard and device have some discussion to describe the device. That discussion may not be based on information in the bootsector. The thumbdrive controller must have an alternate place where the SCSI protocol information about the device characteristics is stored. Maybe the memory on the thumbdrive is mapped so that physical sector 0, is offset from the flash memory zero.

I have done some more surfing. I have learned that the controller on my pendrives is 8051 which has rom and ram (internal and external) capabilites. So the controller is programed to SCSI protocol, supplying device type and product description and flash memory management. Thus the bios of my 3480ct only wants to see a FDD SCSI code device, something my pendrive is not programed to give. Maybe the difference in memory dumps is due to wear leveling where overused memory is mapped out (i've tried a lot of writes of bootsectors) to less addressed memory.
*END EDITED*