I have been bitten by the same bug.

In my case the disk drive started life with the installation of Fedora (although the the computer supplier had used some version of Windows on the disk for testing, which was removed before the computer was supplied to me).  I had no problems using the disk with Fedora for several years.

Kubuntu looked interesting, so I decided to try it by installing it on a second drive which I added to the computer.

Kubuntu installed and I have been using it (e.g. now) and working around the inevitable bugs and inconsistencies...

A particularly annoying bug is the fact that udev fails to see my original Fedora partition.  This means that I can't use the  LABEL or UUID methods for that partition in fstab (udev deletes the entries in /dev/disk and creates new ones each time it is restarted.  "mount" appears to use these entries).  Ubuntu uses the new-fangled "upstart" init scheme (which is annoying on two counts: how it works on Ubuntu doesn't appear to be well documented, and it seems to be mostly set up to emulate Sysv init anyway!).  Having worked my way through this maze (init and udev), I found that script /etc/udev/rules.d/65-persistent-storage.rules appears to be one of the main culprits.

The udev script uses the "vol_id" program to fetch the information about the LABEL and UUID of each disk device.  (remark: the man page for vol_id omits several of the options which vol_id accepts, including --help and --probe-all)
`vol_id --probe-all` reveals that it identifies two partition signatures on my old Fedora partition: a vfat one and an ext3 one.  For some reason (I haven't yet been able to find an explanation in my googling) it is possible to have both at the same time.  The vfat signature is, it appears, always in the first 512 bytes.  The ext3 ones start at byte 1024.  Thus is would appear that it is possible to have the two valid signatures at the same time by either of the following: format a partition as a vfat drive first and then format it as ext3, or (possibly) format it as vfat and then use it and then by chance have the Windows FAT contain a valid ext3 signature (I don't know whether this is possible but it almost certainly has a very low probability).  A key question here is: why didn't the program I used to format the partition as ext3 write nulls over the first 512 bytes?

The solution for me was, as I found on the web, to do "dd if=/dev/zero of=/dev/XXX bs=512 count=1" and hope I didn't mistype it.

However, this took quite a lot of time to track down and I know from my web searching that the bug has troubled a number of people.  It certainly didn't make Ubuntu look very "user friendly".  I believe that the bug should be squashed (or beaten into submission) and that the importance should be above "low".

Some ways to make the process work better:
1.  It would appear to be fairly easy to detect the multiple signatures ("vol_id --probe-all") before udev sets up the /dev/disk entries for a partition and then, if the relevant partition table entry id is not for an MS file system, to offer to wipe the first 512 bytes for the user (with appropriate warnings).
2.  Do the same checks during the installation process for Ubuntu.
3.  Do the same checks in programs such as the KDE "Disk & Filesystem Configuration Tool"
4.  An interesting alternative would be to modify the behaviour of "vol_id" to always check for multiple signatures and then, if vfat and ext3 (or similar) are found, to default to returning the information from the second signature instead of the first (which it does now).  This would appear to have a finite, but low, probability of failure but this probability could be lowered by comparing the relevant areas of the two copies of the MS FAT.