The servers are on premises as all services used by the staff are purely internal so I have to deal with them, that’s why I must “upgrade in place”.
As of 6.0.6 LTS you’re partially right. 6.0.6 is functionally equal to 6.22! Only 6.23 have updates not backported to a hypothetical 6.0.7 release. But I don’t care since I backported most CVE patches from 6.23 to my 6.0.6 packages to stay on the safe side. No issues so far, everything works as a charm.
In the 7.0 LTS release announcement, it lists “OCI support” under the “Changes since Incus 6.0.6 LTS” section.
It does also say "We have been pretty aggressively backporting changes from the Incus 6.x releases back to the 6.0.x LTS releases" but I don’t think OCI was one of those.
You’re right that a lot has been backported. I think that’s less than ideal: a true LTS branch would be primarily bug fixes, and every backported feature is a potential regression.
On the other hand, the packages in Debian/Ubuntu main repos are essentially frozen in time, which is worse.
That’s correct; OCI support wasn’t available in a LTS branch until Incus 7.0 LTS. One of the constraints when backporting fixes/changes into a LTS branch of Incus is that no database schema changes can be introduced. The OCI feature required a database change, so it can’t be part of Incus 6.0 LTS.
I agree with you about the Ubuntu side, since there’s currently no Ubuntu Developer actively keeping an eye on the Incus packages. They’re essentially snapshots of the packaging from Debian unstable at various points of time during the Ubuntu development cycle.
On the Debian side, security fixes are routinely applied to the version of Incus in trixie, along with the occasional bug fix for significant issues. But yes, the version of Incus in trixie won’t get further 6.0.x updates, as that doesn’t follow the Debian release model. (If you know of particular non-minor bug(s) affecting Incus in trixie, please do report that bug in the Debian BTS so that I can triage it. Generally it’s not too hard to cherry-pick specific bug fixes affecting a user.)
Thanks. I use the Zabbly LTS packages on Ubuntu, which for me is the most useful combination (up-to-date Incus + simple ZFS support)
@bensmrs @IronBox Yup, it’s caused by GO111MODULE=off 
Specifically, prior to Go 1.23 tls.{,Load}X509KeyPair() didn’t populate the certificate’s Leaf field and it defaulted to nil. Recent releases of Go do populate the leaf. When building the Debian package the resulting code gets a nil pointer and crashes.
Will be fixed by https://salsa.debian.org/go-team/packages/incus/-/commit/6f513e0c73e3af00ce4e0cbdeb777a2f0a1a7971 .
A recent update on the efforts to modernize Debian’s Go build process is described in the first section of this post: Debian Contributions: Go default compatibility, Trimming build-essential, Python upstream engagement and more! | Freexian.