Hacked -- Improved. Those words are pretty much interchangeable depending on your own view and biases.
No, they aren't in this case. Adding long filenames to FAT, for instance, broke compatibility with previous implementations of the FAT file system, precisely because they were implemented with a hack: invalid directory entries that happened to be ignored by earlier DOS versions, but would confuse other software which was perfectly working until then. Remember the "LOCK" command that Microsoft added in Windows 95 to prevent those utilities from ruining the file system?
Also, I did explain what minor and insufficient improvements to FAT were made, as well as what major deficiencies remained unfixed, so there's no "bias" involved here.
Also, systems using FAT can use extended attributes if they wish. OS/2 does just fine with extended attributes on FAT, and so does cygwin. Just because FAT doesn't explicitly say this is where you stick them doesn't mean you can't write a file system driver on top of it that puts them wherever you want.
Then they're not using FAT, which does not support extended attributes, instead they're using a personal extended file system derived from FAT, which itself is not FAT, is not interoperable with FAT, and will be unreadable and damaged by other software designed for the standard FAT file system. This won't happen with a file system supporting extended attributes, such as NTFS or UDF.
Yes, FAT has poor performance on optical storage, but why would you use FAT on it in the first place? There doesn't need to be one file system that works great in every case.
That's exactly the point, nobody would ever use FAT if it wasn't because of interoperability requirements. It's inefficient on traditional media, and it can be extremely inefficient on non-traditional media, it never works great. Therefore nobody would ever dream to license it for its technology.
Bull. The algorithm isn't part of the FAT/FAT32 standard, it's part of what is known as the VFAT standard, which you don't have to implement.
But there is no such thing as a "vfat standard". "vfat" is the name that Linux informally attached to its file system driver supporting long file names, and that name stuck. The reason is that the native Windows file system driver, with which the Linux driver aimed to interoperate, was called "VFATD", and that was because Windows "386 enhanced mode" drivers used to have a name in the form V-name-D.
Both Microsoft's official specification of the FAT file system, which is referenced by the UEFI standard, and the SD card standard, contain the short name creation algorithm. Beware: that documentation is subject to a restrictive license by Microsoft, and you have to accept it in order to look at the specification.
No, they don't have to only write 8.3 ASCII file names, they can implement any alternative they choose.
And then they're implementing something different than FAT, which is not interoperable, violates the standard, potentially makes Windows XP bluescreen etc. etc.
or install a Virtual File System driver in windows that understands your new layout.
So you're proposing that, in order not to pay licensing fees to Microsoft, a manufacturer should write a device driver for each operating system that currently supports FAT, for all of its revisions past, present and future, for all of the hardware architectures it supports, then distribute all of these drivers with its product, and require their installation before the use of the product? This would be unrealistic if it was possible, but then it's not doable even in principle, because many devices one might want to interoperate with do not have a user-extensible operating system. See Windows RT for example.