There is another option; the zfs mechanism also offers a setting to allow using a newer kernel than the officially supported one.
In the zfs repo, the META file was updated to include 6.0 kernels 14 days ago. From a (very) quick look, there doesn’t seem to be any major commits fixing 6.0 compat issues before then since the previous release. It would probably work fine.
Now, to be clear, I’m absolutely not making any recommendations or suggestions here. I really only did a quick search for commits, am no expert, haven’t tested anything, etc.
Instead the point I’m making is that there are risk trade-offs here. An unstable ZFS+kernel pairing might eat all your data. An EoL kernel might be missing a critical fix. That risk assessment might change over time (say as new vulns are released).
Unfortunately, the current policy makes it strictly worse: by removing the kernel entirely, it means one side of the trade-off is instead an outdated entire system, with possible userland vulnerabilities as well, because the channel needs to be held back.
The first question is around policy: should we remove these kernels completely, or just mask them until a path forward is available, regardless of the mechanism and syntax. We don’t have to do that for every kernel; as noted the combination of nvidia and zfs schedules is currently awkward, and it mostly only happens for the versions just prior to the next LTS until everyone (zfs in this case) catches up.
As for mechanism, I like @vcunat’s suggestion. I also assume, without having tried, that there’s a way to reinstate the removed kernel with an overlay, or a local nixpkgs fork. Again, the policy question is whether we should push users to have to resort to those kinds of mechanisms.