Optional sub-indexing by FreeBSD minor version for packages

During the three months overlap period of two successive minor versions of
supported FreeBSD-RELEASE versions, packages for supported architectures
are built only for the soon-to-be-EOL minor version until its final EOL
date, after which only the highest minor version of the two is supported
(and for which packages are then build). This can be a problem for a small
number of packages, especially kernel modules.

Why can't we have an optional sub-indexing by minor version; something like
${ABI}-minor_version?
Or is this problem with incompatible packages during the three month
overlap of a new released FreeBSD minor version something that "doesn't
need fixing"?

As I see it, we have the following issues during an overlap period:

- It affects a significant number of (package) users, new and experienced
ones alike
(seems a recurring topic here on the forums in one form or another).
- It is rather antithetical to the general objective of planning and
executing updates carefully as it "forces" users to wait for a minor
version update just until the old minor version goes EOL
(The only resolve is to resort to building the port(s) in question).
- IMO it does not help in making FreeBSD more attractive for new users and
general use, o.a. desktop oriented users.
(especially when (graphics) kernel modules are "chasing" current
technological updates, be it adapted from Linux or from elsewhere).
- Looking at the FreeBSD handbook this particular package problem during
the overlap period and how to work with or around it isn't addressed or
explained.
- (As far as I know this has nothing to do with the "pkgbase" that is being
developed.)


For a solution of "package minor-version sub-indexing", I see the following
aspects:
1) Software development & implementation of adding optional FreeBSD RELEASE
minor version sub-indexing to packages.
2) Identification and tagging of all ports for specific packages that could
benefit from this minor version sub-indexing.
3) Additional *temporary* build-time for the overhead of extra packages.
4) Additional  *temporary* storage for extra packages.

The *temporary* aspect relates to the three months overlap period during
the transition period of two successive FreeBSD minor versions. Initially I
feared #3 & #4 could be a problem, but based on replies:
https://forums.freebsd.org/threads/13-2-13-3-amdgpu-doesnt-work.93433/post-655071

and
https://forums.freebsd.org/threads/13-2-13-3-amdgpu-doesnt-work.93433/post-655072
that does not seem an issue. I think the number of packages and storage
requirements do double because for each supported minor version you have
the quarterly and latest branch.

A solution would result in getting/updating a FreeBSD minor version
specific package version when there is one available, for example
13.2-RELEASE versions of the port graphics/drm-kmod (plus related ports)
and the port emulators/virtualbox-ose-kmod, or 13.3-RELEASE versions.

Kind regards,
Eric