What I find odd is:
(a) there are 3 simultaneous production releases (13.0, 12.3, 12.2) - which seems confusing and lack of focus
(b) the development process is CURRENT > STABLE > BETA* > RC* > RELEASE. But the problem is, all developers just work on CURRENT (not RELEASE). So if there is ever a problem on RELEASE, you basically won't get the fix until the next MAJOR release, not the next point release. This also create a weird side effect where major releases only have 2-3 point releases and never matures.
(c) it seems appropriate to only run RELEASE in production, but the problem is - RELEASE is only supported for 3 months after the next RELEASE. 3 months! [1]
(d) this creates a situation where companies basically have to fork FreeBSD just to use it in their production environment (and merge from CURRENT frequently, which by it's very nature is unstable). Netflix has to do this, but not all companies have the huge resources Netflix does [2]
(e) just the simple fact that freebsd.org list 4 releases on their homepage is alone confusing.
These problems has been long documented for over a decade (documented well by @rsync [3][4]), I just feel like I must be missing something obvious as to why FreeBSD does there releases so strangely.
[1] https://www.freebsd.org/security/#sup
[2] https://news.ycombinator.com/item?id=21867202
[3] https://lists.freebsd.org/pipermail/freebsd-hackers/2014-June/045319.html
[4] https://lists.freebsd.org/pipermail/freebsd-hackers/2012-January/037294.html
Don't you mean 13.0, 12.2 and 11.4?
This is pretty common in other software too, isn't it? Ubuntu for example has 18.04 supported until 2023, 20.04 until 2025 and 22.04 (coming out soon) until 2027: https://ubuntu.com/about/release-cycle
Python has 4 supported versions: https://endoflife.date/python, and so does node: https://endoflife.date/nodejs.
There's a couple ways to run FreeBSD in production. Netflix does bleeding edge, and follows CURRENT, which is good for them because they do a lot of changes in the kernel, and want to upstream their changes, so staying up to date on CURRENT makes upstreaming easier which makes their life easier.
The other way is to use FreeBSD as a stable base, and only upgrade when you need it. In that way, you periodically validate new releases, and install new servers on your currently validated release, and leave existing servers with the release they were installed with, and sparingly update between releases when there's something important. Some choose to avoid .0 releases, and some choose to avoid X.Y where X % 2 == 1 (even numbered releases don't suck); although really it was only 5 that was worth skipping. Avoiding .0 releases may be obsolete as well, I seem to recall not having major issues with 13.0, 12.0, 11.0, and 10.0, but it's been a while. I wouldn't rush out to get a new major release, unless there was a very important feature/enhancement though.
Build your application software on a build machine that runs the oldest release that you run, be sure to install the compat_X packages so you can run older software on newer releases. If you run into bugs, expect to fix them yourself (that's what open source software is about, right?), and report them to upstream, and that they may be fixed in future releases. You'll need/want to develop a workflow where you fetch the upstream source for a release, apply your patches, and build world, release validation involves checking if your patches are still needed and updating them to still apply if needed. When releases are patched (ex 13.0-RELEASE-p7), it almost never breaks anything, so I would almost always build from the latest release patch when building a new server (there may be some exceptional versions), but I would read announcements to see if the change was relevant before updating servers. Minor versions are usually not a big deal either, but major versions often need patches updated and sometimes have major behavioral differences.
Now to your bullet points:
a) This shouldn't be confusing. Although maybe the presentation on the security page[1] is more (or less) clear. The 13.X series was released April 2021, and is expected to get security updates and critical patches until EoL, which is currently expected to be January 2026. The 12.X series was released December, 2018 and EoL is expected to be March 2022. This is a roughly 5 year commitment, rationale in the announcement [2]. Each minor release is supported through either 3 months beyond the next minor release of that major release or until the major release EoL, whichever comes first. FreeBSD plans to not have major releases more than once every two years, so there's at most three major releases supported at any given time.
b) It depends on the scope of the problem; bug fixes do get released onto branches, when it's justified. The expectation is that RELEASE branches are mature on release and won't change much. This isn't great if there's a bug that's important to you, but doesn't justify a fix in RELEASE for upstream.
c) This is at odds with your point in a. The FreeBSD team can only support so many releases, so they've said when a minor release is superseded, you get 3 months notice. Actually, if you follow along with upcoming release announcements, you get a bit more notice: 13.1 is currently in the release process, with a target date of April 26 (and the schedule was announced February 1); so we can anticipate 13.0 will end support near the end of July.
Also, it's important to note that the end of support doesn't mean your server turns into a pumpkin; just that you no longer have security advisories that specifically discuss your installed OS. If you keep abreast of security advisories in general, you can look into things that are reported on the software in base, and the currently supported releases and decide if it likely applies to the older versions and either backport fixes/workarounds or upgrade to a supported release.
If you consider your point in b, that you're not getting all that much support on the supported releases, losing support doesn't seem to be that big of a deal either. If you run into a bug, try it on one of your more updated servers (or update a server to try it on); if it's fixed, great, upgrade your impacted servers; if it's not fixed by upgrading then figure out how to fix it and if it's easier to fix in place or upgrade and fix at the same time.
e) This seems to be a rehash of a, but also c. If you want releases supported beyond the next release, they need to be listed. If you want to know what's happening with releases, the upcoming version should be listed. If you're having trouble picking which release to use, use the first one in the supported list, that's why it's there.
[1] https://www.freebsd.org/security/#sup
[2] https://lists.freebsd.org/pipermail/freebsd-announce/2015-Fe...