Out of curiosity, why work proceeds this way not skipping directly, say, to 6.18 LTS? Just curious.
As far as i remember the justification was to allow less breakage on the linuxkpi end and, when the linuxkpi aligns, allow for drm-latest-kmod to have a more recent version than what was shipped by default. This has the advantage of, on ocasion, allowing support for new hardware before the next FreeBSD release.
On the other hand I don't think it's more beneficial to go minor by minor instead of just going for the next LTS. As is it's one developer doing most of the work and as this is all dependent on Linux upstream code it's easy to break users. for example by shipping a mesa version on 14.x that is not supported by the amdgpu driver. Or linux kernel to freebsd stuff that do not map thus breaking firmware uploading on newer intel gpus. Or the fact that gpu-firmware must be updated more often than every major. Or the fact the kmod repos for the latest minor are still broken.
I.e., FreeBSD is the largest of the BSD OSes but it still has to make do without vendor support (excepting some cases), very few hardware developers (with access to actual hardware), very few (and overworked) maintainers, a ci/cd backend and package solution that is evolving and needs improvements for non server use-cases, lack of actionable bug reports (which tied to few devs is a reason for sometimes long resolution times).
But despite all of the above today you are more able to use freebsd as a general purpose os than before. And it's free, open source, user driven and you are not the product.
