V případě LG mechanika dělala to co měla dělat podle ATAPI specifikace pro mechaniky CD-ROM. Výrobce musí někam pověsit flash firmwaru, a ve specifikaci ATAPI to pochopitelně popsané není. Nevím jestli to dali na stejný interface jako CD-R operaci buffer flush ještě před uvedením CD-R mechanik, nebo až poté. Faktem je, že driver dělal co neměl. V případě Samsungu byla vina i na straně výrobce, ale to nijak neomlouvá chyby Linuxu. BTW to "poněkud divné chování Linuxu" je ve všech třech případech prostě špinavý hack, ve dvou z nich doprovázený závažnými bugy.
V oblasti HW těch standardů moc není. A kde jsou, tam jde pouze o doporučení, kterými se výrobce může a nemusí řídit. Navíc specifikace protokolů a chipů spoustu věcí nepopisují. Například protokoly prakticky u žádného zařízení nepopisují způsob updatu firmware, a výrobce ho musí nějak umět.
Jinak tomu "bastlu od výrobce" se říká driver :), a na rozdíl od generického naslepo psaného driveru je psaný se znalostí konkrétního zařízení, podporovaných operací, podpůrných obvodů, firmwaru, operací které umí navíc proti specifikaci nějakého čipu, se znalostí efektivity jednotlivých operací, časování atd. Generický driver střílí od boku to, co bylo napsané ve specifikaci předchozí generace nejspíš úplně jiného zařízení postaveného shodou okolností na stejném čipu, a vývojáři to zrovna doma zafungovalo. To se pak nedivte, že ty drivery stojí za starou bačkoru.
Windows se důsledně vyhýbají operacím, které nepotřebují. Pokud operace kterou Windows nepoužívají způsobuje nějaké problémy, MS to jaksi nevadí. A protože MS necertifikuje například shodu se specifikací UEFI, ale bezproblémový běh s Windows, tak to výrobci neomlátí o hlavu.
Před kritizováním výrobců by to chtělo zamést si v kernelu - minimálně používat dokumentované interfaces a testovat na reálném HW.