>> the question is if the stability issues are due to the driver, or due to the driver's interaction with the rest of the kernel.
> A distinction without a difference. The driver has no purpose and no function other than inside the kernel.
Actually, in this case it is a very important distinction.
let's put it another way.
Are the bugs in the graphics logic, or in the interaction with the rest of the kernel.
If the bugs are in the graphics logic, then they would remain if they were separated the way the Pi broadcom driver is.
If the bugs are in the interaction with the rest of the kernel, then an API like the Pi has would allow us the best of both worlds, good graphics performance, and clean interaction with the kernel
The driver vendors keep wanting to have a stable API for their interaction with the kernel, and the kernel devs (for good reason) refuse to freeze the kernel internal APIs. But if the API to the device is defined and frozen by the firmware interface, everybody wins (except those people who want to make the graphics hardware do different things)
Yes, the graphics hardware could start scribbling to any part of memory that it wants, but technically, so could any bus-mastering controller card, and there have been very few cases where bus-mastering network or drive interface cards have caused problems from this.