They are always on the table. They aren’t desirable outcomes, which is different.
Fedora kernels already track the upstream “stable” release series. You’re talking about the “longterm” series, which is a different track.
What I’m saying is that it doesn’t actually matter what kernels we have, how many of them there are, and what processes we have. Because we have no people to do anything. Red Hat does not commit resources to fix problems discovered by Fedora, which means it doesn’t matter if the problem is in 7.0-rc6, 6.19-stable, or 6.18-longterm. They are still not getting fixed.
And combined with the architectural complexity of actually making the packaging, install, and bootloader infrastructure sane and stable with multiple kernel variants, it does not make sense to go down that rabbit-hole.
I’m saying this as someone who is maintaining kernel trees and alternative kernel flavors for Fedora Asahi Remix and CentOS Stream Hyperscale: it’s a bad place to be, and I would rather not be here if it wasn’t absolutely required.
I would rather focus on the core problem with the Fedora kernel, which is that the sole kernel maintainer is massively overworked and isn’t able to engage on Fedora kernel bugs and we need more people that engage with the different subsystems in the kernel to support the Fedora kernel. Then things like “Vulkan crashing applications on NVIDIA hardware” and your touchpad issue can actually have hope of being fixed. The upstream Linux kernel project has no formal singular bug tracker, and there is no reliable way other than sending emails to the relevant subsystem mailing lists. But the upstream Linux kernel project relies on Linux distributions to have their own maintainer teams to funnel those bug reports and engage productively upstream. Fedora needs to be doing more of that, like we do for Btrfs.