...
Na prvním místě vycházíte z toho, že v Sound Devices záměrně udělali vlastní modifikaci FAT32. To je ovšem pouze domněnka. Těžko říci, jestli jde o záměr nebo prostou chybu/neschopnost.
Na druhém místě argumentujete že SD mají právo modifikovat FAT32 stejně jako MS. SD na rozdíl od MS nejsou autorem FAT32, takže nemají co měnit specifikaci.
Technicky samozřejmě SD nikdo nebrání implementovat si vlastní modifikaci FAT32, která může být klidně nekompatibilní s čímkoliv jiným. Podobně mohou třeba napsat vlastní FS. Jenže proč v SD vlastně ukládají data na FAT32? Workflow jejich zákazníků vypadá tak že nahrají zvuk pomocí zařízení od SD, pak přečtou data ve Windows a zpracují zvuk v nějakém specializovaném SW. Je tedy v zájmu SD, aby data z jejich médií bylo možné přečíst ve Windows. Proto by se měli držet specifikace FAT32 od MS. Pokud jsou v rozporu se specifikací FAT32 od MS (a můžete tvrdit že je to "FAT32 podle SD"), tak mohou logicky čekat v budoucnu problémy s kompatibilitou s Windows, až MS začne konkrétní rezervované bity využívat jiným způsobem než dosud.
Z toho vyplývá, že v SD buď záměrně ignorovali kompatibilitu s Windows (a pak dobře jim tak), nebo udělali chybu při implementaci (a pak dobře jim tak).
To že nekompatibilní implementace FS může způsobit po přimountování problémy není nic nepochopitelného. Když si například vymyslíte že budete soubory označovat flagem ATTR_DIRECTORY, tak FAT32 driver napsaný podle specifikace bude zacházet se soubory jako s adresáři, a když zkusíte přečíst soubory z podadresářů (zřejmě binární řezanku), s klidem může zapsat do "adresářů" čas poslední modifikace souborů, a tím soubory poškodit. Podobných scénářů jistě dokážete sám vymyslet víc.