The growing image-processor unpleasantness

Most, if not all, cameras based on a CX-3 use a "smart sensor" (a.k.a. "YUV sensor") that integrates a raw (Bayer) imaging sensor and an ISP in the same chip. Those have a tendency to target low-cost applications, and don't focus on image quality. A UVC camera could however be built around a good quality raw sensor and a powerful ISP (and possibly eve an h.264 or H.265 encoder to lower the USB bandwidth at high resolutions and frame rates). High-end webcams have such an architecture, and I wouldn't be surprised if some even ran Linux internally (I know of multiple webcam vendors who prototyped webcams based on an SoC running Linux, but I don't know if any are available on the market today).

> For the most part of Linux history, the camera API, V4L2 is just a buffer management interface. There has never been a userspace middle layer that provides good and refined camera service to the application, nor has there been a good way of implementing it (PulseVideo?).

That was right, and the libcamera project has been created to fill exactly that space.

> The camera stack of Andrroid may not be the best design in the world, but I do consider it to be on the leading edge of usefulness to the majority of application of users. The Chromium people just want to bring some of those back to Linux.

There seems to be some confusion here. Chrome OS uses the Android camera HAL3 API internally, but as far as I know, hasn't published any plan to push that API towards all Linux platforms. What they refer to as "kcam" today is a kernel API that plan to use as a V4L2 replacement, and the current design places it at an even lower level than V4L2. The gap between the kernel API and applications would then be larger than with V4L2 (and it's already pretty large there, as indicated by how Linux has no open-source IPU6 support today).