I think the suggestion there would be to find someone who is willing to maintain the extension when upstream does a new release.
More generally, GNOME has been in the feature removal business for a long time. So even if something is in the supported feature set today, there is no guarantee that it won't be removed tomorrow. And that's one of the ways in which it's not like kernel development. Once a userspace visible feature lands, it won't get removed. Linus will yell at you and revert your changes if you break users in that way. GNOME is frequently removing features, and so as a result, they can't be trusted. Moving something to an extension is a negative value add to users. Worse, it breaks trust with your user base. Because GNOME has done this to me, it's going to be a long, long time before I trust GNOME again.
What you're saying seems to me the equivalent to saying "If a kernel driver is a critical part of your workflow and usage model, then then run far away, the kernel driver API is unstable and the driver maintainer might get hit by a bus." Because as I have said before, the shell extension API is really not similar to kernel's userspace -- it's closer to the kernel's driver API, in that you get complete access to the shell's internals, you can muck it all up and crash things if you're not careful, the API is unstable, you have to follow upstream closely to really take advantage of it... but if you do all that then it's a very powerful tool, and you can do things that are not possible in "userspace" (i.e. outside the shell).
And the fact is, the kernel does remove old and broken and unmaintained driver APIs. That's your prerogative to do to that, as it is GNOME's (and KDE's) prerogative to remove legacy APIs and features that are not pulling their figurative weight in usefulness. I'm not trying to convince you to use or trust GNOME, I'm happy that you're using KDE and it works for you. But I wish you would not say these falsehoods without an understanding of how GNOME is actually developed, because from my perspective the technical process is extremely similar to that of the kernel, and heavily inspired by it. So please don't forget, the apple never falls far from the tree. If you have some insights on how to plug this maintainer gap that you think GNOME is suffering from, then let's talk about that.
As far as we are concerned, out-of-tree modules do not exist. The module interface is only for in-tree users, which are fully supported. GNOME takes the position, or at least apologists like you, that out-of-tree GNOME extensions are a good thing. As far as Kernel developers are concerned, out-of-tree modules are never an answer. Device drivers should live in the kernel. Period. If Nvidia chooses to do otherwise, that's their problem. But we didn't kick Nvidia out of the kernel.
GNOME kicked 2-d workspaces out of the core DE, because they didn't want to support it. They think that they want to keep things "simple" for their users. Google "GNOME Feature Removal" and look at the history. They took perfectly working features and ejected them from GNOME. We don't do that in the kernel, unless we are sure there are no users. And if we are wrong, and people complain, we'll put the feature or architecture support back.
>We don't do that in the kernel, unless we are sure there are no users. And if we are wrong, and people complain, we'll put the feature or architecture support back.
GNOME unfortunately does not have enough maintainers to do this. If you'd like to help out, please contribute, or help direct some others to do so. That might mean helping to maintain some extensions that you're using. If you don't want to help, and you want to use KDE, that's understandable too -- but please understand what the real issue is.
>Device drivers should live in the kernel. Period.
It would be great if it was technically possible to do this with GNOME, if this is your goal, I would encourage you attempt to merge all the hundreds of extensions together into one big tree, resolve all the conflicts, and then maintain that. It's probably going to be a lot of work, and will break a huge number of things, and if you don't want to do it... well now you understand why GNOME maintainers don't either. Until that happens, people have to stick to another approach: extension maintainers just have to use CI to check their extensions against master and keep it updated.
Secondly, extensions are not the answer, because extensions are inherently unstable. If you think the answer to supporting features is via extensions, then of _course_ GNOME doesn't have enough developers. Some featuers need to be in the core DE --- as 2-D workspaces was once a core feature. Ejecting features from the core feature set, and trying to implement them as extensions, is a receipe for P-A-I-N. It certainly isn't how KDE and XFCE handles 2-D workspaces; there it is implemented in C++ or C, and not in some Javascript extension language using unstable primitives that randomly change from GNOME version to GNOME version.
My Goal is to use a Linux Desktop Environment which meets my needs. And part of my needs is certain well-defined feature set which includes 2-D workspaces, and that they **NOT** be implented as an extension. Because extensions break. All. The. Damn. Time. I've been around since the very early days of GNOME, and GNOME had 2-D workspace support for years and years, and it was not a big deal. It was ejecting features from the core, and implementing them in unstable Javascript which is what caused the problems.
If GNOME simply said, F-U to certain classes of users, we don't think certain features deserve to exist, I'd probably respect them a bit more. I still wouldn't use GNOME, but at least they'd be honest. My complaint is trying to assert that extensions are an answer, and they're not, because it's really unfair to trick users into relying on something which is ultimately built on quicksand. Better to have a small feature set which you can support well, rather than a randomly fluctuating feature set which arbitrarily breaks across distro upgrades.