>Exiting unexpectedly should be a risk of battery exhaustion, users closing without saving, hardware failure, or power loss.

Yes but all of these things still happen anywhere and the apps themselves are the only place that can be fully prepared for that, with cloud-synced web apps this is also not a problem. A lot of Linux users really seem to hate using cloud services though, for those users it's apparent that avoiding data loss is an exercise in self-flagellation.

>The idea of your desktop session just crashing out just shouldn't happen and indeed doesn't happen with i3wm KDE or windows.

Well again, that's a nonsense comparison because none of those have a comparable addons system.

>The fact that extensions can crash is unremarkable the fact that they can crash the session itself is extraordinary. A windows 95 level of bad.

No not really. You seem to think the alternative here to monkey patching is a system that doesn't crash. It's not. The alternative is to load binary plugins into the display server which is even worse and has a higher risk of causing crashes and memory leaks.

>User: gnome lacks functionality Gnomie: but it has powerful extensions User: gnome extensions can crash the session! Gnomie: You don't have to use extensions!

I've not seen anyone here saying that, I'm certainly not saying it. I wish you didn't ignore the part where I said to just fix the crashes in the extensions. I also wish you wouldn't turn this into a conversation with hypothetical users. You're talking to a real person here.

>You either have to deal with potentially unstable extensions or limited functionality. Neither is particularly reasonable.

Yes, welcome to engineering. It's the art of being forced to decide between two bad solutions because you don't have enough time to do it right. If you have a lot of spare time then I suggest you volunteer your time to do it, and figure out how to do it in a way that benefits everybody (not just gnome).

>Characterization of the indefinite and indeterminant lifespan of objects as a normal part of gluing a compiled and garbage collected language is simply normalizing pathology. It seems painfully obvious that the dependency relationship expressed in the JavaScript should be mirrored in the c code allowing it to remove the garbage before the system falls over. This seems painfully obvious when the memory is allocated for an ephemeral purpose like a frame of animation. Can we not destroy everything related to frame n upon drawing it?

This again is more nonsense. No, you can't because the longer you wait the longer your GC pauses will be. This is a problem with any stop-the-world generational GC and it's only made worse by plugging foreign objects into it. The solution would be of course to improve the GC (there are a lot of ways to do this) but then it becomes a mozjs problem. GNOME Shell is just a downstream and can't do anything about it. You're barking up the wrong tree here.

Please just avoid talking about this unless you can propose a solution to the problem, if you can come up with something good that works everywhere and is easy to use then a lot of other projects will benefit from it. If you can't then this discussion will go nowhere. The most that could be said otherwise is "don't use GNOME" but I think it's safe to assume you were already doing that.