The problem of camera diversity is not limited to open source either, because a similar infrastructure to handle all the different cases must be replicated by closed drivers as well. I don't know about Macs, but the Surface laptop is a Windows beast.
Many SLRs are already well supported, though the open source stuff doesn't focus on low latency conversions, which is needed for viewfinders, or focus control, etc.
I did a side-by-side comparison of a Micro Four Thirds camera (4/3" sensor) and an iPhone SE (1/3" sensor) and the performance was... pretty much the same.
And I'm not talking about some ML interpolation wizardry or automatic face beautification; I was photographing barcodes and testing how many were readable in the resulting images - hardly something Apple would have specially optimised for.
The iPhone has a much smaller sensor, a much smaller lens, costs less, and manages to pack in a bunch of non-camera features. To be competitive in the modern cell phone market your camera has to be straight up magic.
If I have to rewrite stuff for low latency, I'd rather start it as an independent library so that other projects can reuse the code.
In reality, UVC is not suitable for a phone, so we can't leverage that. There are some camera drivers in the kernel already, but not necessarily ones that we could buy or meeting our expectations. Even if there were, that still leaves us with the problem of connecting the cameras to applications in a standard way, so we can't really avoid working on libcamera.
edit:
This would also resolve the dilemma of having complex camera drivers either in kernel or in a library. It could be in userspace while the kernel provides a small kernel module to make it work (like v4l2-loopback, or not unlike FUSE for filesystems).
So the interface is the same, it's just split over many device and platform specific subdevices, which normal apps can't really be expected to understand.
The low end of professional-ish cameras is great in lots of ways, but they all have annoying trade-offs. To be fair I'm sure any janky POS I built would too.
https://semiconductor.samsung.com/image-sensor/isocell-plug-... EIS video: https://images.samsung.com/is/content/samsung/p5/semiconduct...
Unfortunately I never got one and it now looks to be unavailable. I don't know if Samsung would have had interest in Open Source efforts to support the modules.
VCX objective camera evaluation links: https://www.dhd.com.tw/wp-content/uploads/2020/11/VCX_Whitep... https://vcx-forum.org/
I assume most people have no visibility of the effort of hundreds of engineers who work on behalf of the big smartphone companies tuning for what happens in the image pipeline between camera/raw Bayer data to what your app receives.
There is a reason the quality of pictures in phones has got so good - lots of tuning, quite a bit of magic, as well as software and hardware co-optimization.
Reason enough to support purism.
