I some ways an early boot kernel only failure is easier. Late boot failures like that, could just as well have been something changing in wayland/X/gdm/mesa/dbus/whatever at the same time. And then if it turns out everything but the kernel is constant, its easy to take a wild guess and look for something in say the DRM/GPU driver in use vs the entire kernel. Although last time I did that turns out it wasn't even in the GPU specific code but a refactoring in the generic display mgmt code. Still ended up doing a bisect across like 5 kernel revisions after everything else failed. Which points to the fact that if linux had a less monolithic tree it would be possible to a/b test just the kernel modules and then bisect their individual trees, rather than adjusting each bisect point to the closest related commit if your sure its a driver specific problem. There is a very good chance that if say a particular monitor config + GPU stops working on my x86, the problem is likely in /drivers/gpu rather than all the commits in arch/riscv that are also mixed into the bisect. Ideally the core kernel, arch specific code, and driver subystems would all be independent trees with fixed/versioned ABIs of their own. That way one could upgrade the GPU driver to fix a bug without having to pull forward btrfs/whatever and risk breaking it.