Every single X server you list is a fork of XFree86, and every X server I'm aware of is a fork of the original X11R1 (or later) release from MIT.

Please cite a single independent implementation of an X11 protocol server.

It can do Go.

Only ones that it can't is C/C++ (probably because that started as Apple only IDE) and .NET (that started as extension for Visual Studio).

They started Fleet that can do all of them, as a response for VS Code. But then came AI and Cursor probably took a large chunk of their users. So they redirected resources (like Zed that paused their collaborative features to focus on AI). There is currently a closed EAP for Cursor like ide based on Fleet. And their Git client as separate app.

Microsoft itself admits there are performance issues with NTFS, which is one reason they created ReFS.

For example ReFS removed the MFT which caused various problems.

The Security Manager was dead as soon as applets ceased to be relevant (which happened a long time before WASM appeared btw.). Deploying the Security Manager requires designing the application up front for it as well as maintaining policy files. Most developers are not aware how to do either.

But its biggest weakness is that it has to restrict a lot of overly powerful APIs. That's like spooning water with a sieve. It would have been better to let the host application restrict which APIs are visible in the first place, like it is done with browser APIs.

The projects that didn't upgrade so far are either dusty business-crirical applications that nobody cares to touch or that utterly deprioritize upgrades unless circumstances force them to. Most of the new features make a lot of sense, but nobody is going to gamble their job on forcing an upgrade just to being able to use them.

To suppress things like `System.exit(0)`, agents can be used. Proper sandboxing solutions would be VMs and containerization technologies. Achieving perfect sandboxing within a process is hopeless anyway.

I'm not aware of any tech other than wasm that I could be using to implement decent-auth: https://github.com/lastlogin-net/decent-auth

Things like JVM and .NET are great, but not designed to be embedded other languages.

I think the problem is basically because the build system has to be implemented using some ecosystem, and no other ecosystem wants to depend on that one.

If your "one build system to rule them all" was built in, say, Ruby, the Python ecosystem won't want to use it. No Python evangelist wants to tell users that step 1 of getting up and running with Python is "Install Ruby".

So you tend to get a lot of wheel reinvention across ecosystems.

I don't necessarily think it's a bad thing. Yes, it's a lot of redundant work. But it's also an opportunity to shed historical baggage and learn from previous mistakes. Compare, for example, how beloved Rust's cargo ecosystem is compared the ongoing mess that is package management in Python.

A fresh start can be valuable, and not having a monoculture can be helpful for rapid evolution.