Quality problems with code at this magnitude aren't really a technical problem (i.e. not something you can fix by asking the same programmers who created the problems to fix them.) It's rare that good programmers could write code as badly as these patches demonstrate. Even actively-harmful coding standards directed from the top down wouldn't cause this kind of code.

Instead, the kind of code that ends up in these driver blobs is caused by, in essence, a political problem: they simply hired bad programmers. The only way to fix that, is to demand that the driver vendors' management teams adopt higher standards for their software hires: that they fire many of the programmers they have, and hire new ones in a much more stringent process. And probably also pay them more, because that stringent process will likely choke their existing funnel out of existence.

It's much the same as, say, finding that a company is using a low-quality outsourcing firm. Would you say that there's a technical problem inside the outsourcing firm? No, you'd say that there's a management problem in the choice of outsourcing firm.

I don't know if this applies so much at the phone / laptop level, but for embedded devices, the example code / reference drivers are often terrible, but it's not entirely fair to blame the devs. This issue is usually not so much that they're bad programmers and more that they're good electronics engineers who, once the hardware is done, are the only people with the knowledge required to implement the drivers.

And the same vendors will suddenly write better drivers with a new unfamiliar OS?

No, but the drivers and kernel will be updatable independently, and the drivers will be sandboxed to their own process with limited permissions.

The quality of the user experience will be better as a driver crash won't bring down the device.