> But it is my understanding that this is already the reality on mobile devices - most of them are based on a private kernel tree with a whole bunch of closed source drivers added.
On mobile devices, the proprietary drivers are in user space. The kernel can be recompiled (because providers are forced to provide the source for their modified kernel), with necessary patches, which helps create alternative ROMs. This probably won't be a possibility anymore with a kernel for which you don't need to provide the source code. The drivers will probably be back in the kernel and you won't be able to patch the kernel to make it work on unsupported, newer / alternative user space.
> On mobile devices, the proprietary drivers are in user space.
So, the situation would stay the same regarding that.
> The drivers will probably be back in the kernel
Manufacturers putting drivers back into the kernel would be a step back for them since it would be more work than just using them in user space given there is a stable driver API.
> and you won't be able to patch the kernel to make it work on unsupported, newer / alternative user space
I think people forget that Fuchsia is more than the kernel. It comprises more things than Linux. Being based on a microkernel design, the kernel part represent just a small surface of the whole 'system interface'. All the rest is in the user space. The Android (platform) part of the system will be layered on top of this 'system interface', and will not define all the user space per se alone. This 'system interface' is well defined and documented [0] and, similarly to the Android (platform), they also have a CTS that tries to ensure that [1]. For example, the software layer implementing the product representing the Nest Hub is outside the Fuchsia platform, as will be with the Android (platform). So, a manufacturer implementing a particular feature inside the kernel, or in other component like drivers, will still result in its device having a 'system interface' at least compatible with the oficial Fuchsia one; if it's not, but offers something more, we all would be in the same situation where the provider bundles that features in closed blobs anyway.
I think Fuchsia's decoupled system architecture will make using an alternative user space not a big problem, if not even easier that it is with Android based systems.
On mobile devices, the proprietary drivers are in user space. The kernel can be recompiled (because providers are forced to provide the source for their modified kernel), with necessary patches, which helps create alternative ROMs. This probably won't be a possibility anymore with a kernel for which you don't need to provide the source code. The drivers will probably be back in the kernel and you won't be able to patch the kernel to make it work on unsupported, newer / alternative user space.