I've tested DLA 5.20 and Sonic Drag-to-Disc 9.05. Neither one will allow XP to write to a UDF formatted hard drive. I have not yet tested InCD, but my guess is that it won't work with hard drives either.
The only product I've seen so far that claims to write to UDF hard drives is SAI's WriteUDF! (dead link), but it's $80.
There's also the free DVD Write Now, but I doubt it will work either. The last time I tried it, it wasn't the most stable thing in the world (not good for a program that has a filesystem driver component), and it only claims to handle UDF 2.01 writing. I'm not sure whether or not that would prove problematic.
The route I've gone personally is NTFS, along with putting the NTFS-3G for Mac installer on the hard drive. Since OS X has read-only support built in, this works well.
If you want free, cross-platform, and no file size constraints, NTFS is going to be your best bet. NTFS-3G for Mac is free and performs "well enough." The company backing the free NTFS-3G also sells Tuxera NTFS for Mac, which is supposed to be much faster. There's also Paragon's NTFS for Mac software as well, but it's not free either. At least there are options.
Ext2 will also work, and there are free drivers available for both Windows and Mac, but you have to have a secondary method of getting the drivers onto your host systems. This is also a problem for NTFS and Linux. I don't know what performance or stability of the various Ext2 drivers is like.
Either you're lucky to never have had corrupted data, or you're unlucky to never had noticed your data was corrupted.
When you perform an action that should write on a disk, most operating systems put the write operation into a queue. From time to time, they flush the queue. (I'm calling it a queue here, but actually operations can be performed out of order, operating systems do this when it's faster and gives the same final result.) This can make the write operations a lot faster, both because the system tries to perform them when it doesn't have anything better to do and because it can group them intelligently.
If you happen to unplug your device before everything has been written, you may miss the latest data. Worse, if the OS has been performing operations out of order, you may put your device into an inconsistent state and lose more than the latest data.
Some operating systems go into a more conservative (but slower) mode for removable devices, to reduce the risks associated with unplugging the device before it has been unmounted.
ADDED:
Doing operations out of order is sometimes not just a matter of speed. Cheap flash media (that doesn't to sector reallocation at the hardware level) has a limitation on the number of times you can write over any given sector. If you naively write all changes as they happen, this can kill the sectors that contain the file allocation table on a (V)FAT filesystem (the most common case for removable drives) or the journal on a typical modern filesystem. (See e.g. this discussion of sync on the Linux Kernel mailing list.) Here, not updating the FAT or journal every time a file is written to is not just a big performance gain, it's also good for the lifetime of the hardware.
Until recently, Linux only gave a choice between sync (write all changes as they happen) and async (write whenever it's convenient). Recent versions introduce the flush option for FAT filesystems, which is somewhere in between (flush all delayed writes as soon as the disk becomes inactive); it's on by default in Ubuntu 10.04.
On a different note, unmounting a removable drive ensures that no application has a file open. If you don't unmount before unplugging, you won't notice if you have unsaved data until it's too late. Unmounting while a file is open also increases the chance of corruption, both at the filesystem level (the OS may have queued some operations until the file is closed) and at the application level (e.g. if the application puts a lock file, it won't be removed).
Best Answer
While it is not 100% safe to remove a FAT volume without unmounting, it is safer than NTFS.
exFAT has the following differences to FAT 32:
File size limit is now 16 exabytes.
Format size limits and files per directory limits are practically eliminated.
Like HPFS, exFAT uses free space bitmaps to reduce fragmentation and free space allocation/detection issues.
Like HTFS, permission systems should be able to be attached through an access control list (ACL). It is unclear if or when Vista will include this feature, however.
Since caching is handled much in the same way, you should get the same unmounting behavior from exFAT as you did from FAT32.