It's quite lean, it requires a lot less code than OpenGL does! But it does require some -- partly because there's some cruft left in the spec, but also because there's always some work that can be shared. SPIR-V and NIR being the big ones, everyone needs a shader compiler, and a good chunk of the work around that can be shared. And then the stuff on top of that like pipeline caches. That's stuff where the spec got it right, but just everybody needs some infrastructure.
There's also things like subpasses, which, if you can ignore it, you can just use a "default" implementation that acts like a desktop immediate-mode GPU and ignores subpasses. Not always appropriate for a mobile GPU or a tiler, where subpasses are meaningful to you, so it's provided as an optional helper.
Then there's just leftover spec mistakes like VkFramebuffer, where the spec is just thicker than it should be. That's fixed in future spec versions but someone needs to implement the old way.
VkFramebuffer is gone in future versions or vulkan? By what was it replaced? (I am being lazy here, asking instead of going to read the latest specs). I coded my everyday video player using vulkan (very conservative), I would move my code to this new thingy once it's in mesa. What I liked with vulkan, on the main thread of my video player, I just post vulkan non-blocking commands, I don't even need a video thread! I can even use the main thread to mix fast enough the audio data!
NIR is a sweet spot for me (lean C89 code with benign bits of c99/c11), even though I would like a configure "switch" to remove all non-breaking algebraic optimizations from the vulkan drivers (I used to do that myself for a good while, near 0 performance impact) since it is redondant because those should be directly done in spir-v code.
Since I am an AMD user (I play video games, now all the ones I play have a vulkan backend), even if I really dislike a bloody lot c++, I am grateful to valve for ACO (because llvm is beyond toxic, even from a c++ point of view). But I wish ACO would manage to add the possibility for hand-coded assembly shaders (AMDGPU ISA is public and really ez to code), just need a few relocation types (writing an assembler should not be a nightmare like with hw architectures using bazillions of relocation types).
The Mesa codebase does feel quite weird from afar but it would fun to contribute. I know compilers but not much about graphics.
Unfortunately I don't have a box to try wacky drivers on so that may block my efforts to embarrass myself in one more domain. Couldn't tell whether they test in VMs or physical boxes (or userspace?)
The Mesa driver is all in user space, it's simply a library. You can develop it without messing with your system or any of the applications that are generally open.
Developers can just build and install them to some user-controlled directory (e.g., $HOME/opt) and run from there with LD_LIBRARY_PATH and other similar variables. You can wrap all the variables in a script and run your custom-built mesa with simply "$ with-custom-mesa glxgears" and then glxgears will be using your custom (and possibly broken) driver, while everything else will still be using the default drivers from the distro.
You could use containers such as systemd-nspawn, but it's much more complicated than simply using $HOME/opt.
I heard it said that OpenGL drivers are essentially run-time compilers :) Working on a driver like this would not actually involve much knowledge of graphics. It's more an exercise of careful spec interpretation and deep knowledge of hardware-level interface.
