There is a ton of value in legacy. Maintaining backwards compatibility is a big deal. At some point you end-of-life a feature, but you generally don't want to make breaking changes. The tty is probably going to be with us for many more years yet (decades), so I don't see it getting end-of-lifed.

It is a big deal, but honestly as somewhat of a visionary I would rather see an open source platform that decided to cut ties with such a legacy system that causes short term pains in favor of longer term advantages. That transition has to happen at some point for a platform to become more versatile, and if it's put off indefinitely, that just resigns itself to being not the best possible platform it can be.

The thing you have to keep in mind is that once you start cutting ties with legacy systems, breaking changes will keep happening. Today, it's key-up events. Tomorrow, it'll be something else. And eventually, the new and shiny subsystem you introduced today will be considered legacy code by someone else, and it too will be tossed out and replaced.

In the end, you'll be choosing between a platform that requires you update every piece of software you maintain every six months and a platform that doesn't. And while the former might seem better from a pure-ideals perspective, the latter is vastly preferable for actual usage. (That's why so many people use Windows, and it's why I now run Linux on my MacBook.)

That's an interesting perspective, but it seems unlikely that that is the main or even an important advantage Linux has over Windows. After all, you can't really run old Linux binaries on a new Linux system without strong determination and a lot of time. There are many others, including its (essentially) fully open source nature definitely being up there.

You're correct that this is not an advantage Linux has over Windows; both Windows and Linux strive to maintain strong backwards-compatibility guarantees. It's an advantage they both have over systems like macOS.

And while Windows maintains near-perfect binary compatibility (I've run programs on Windows 10 that were last compiled a decade ago), Linux instead has excellent source compatibility. I've successfully compiled and used decade-old Linux utilities with no problems.

This difference speaks to the different economic philosophies these platforms have. Microsoft expects you to buy software in a box at a store and use it forever. Linux expects you to use free software developed by volunteers. And Apple expects you to pay over and over again to avoid losing functionality.

The Linux kernel is famous for trying really hard to maintain ABI backwards-compatibility.

In practice this means that statically-linked executables from a decade ago will run just fine on Linux today, at least as far as interactions with the kernel is concerned (interactions with other parts of the system, it depends). The same is not necessarily true of dynamically-linked applications because user-space libraries' maintainers are not as exacting about backwards-compatibility. Note that this is not an argument for static linking, at least not in its current form.

You forgot to justify where you need to have interesting features in a tty instead of graphical environments where there is no such limitation.

> Sure, you can fix it, you just might have to [...] say goodbye to running all the programs currently out there.

One problem with doing this is that the only reason anyone uses Linux is to run programs that are currently out there. If Linux started to make breaking changes like this, people would switch to some other operating system that didn't break their software.

Sure, lots of people use macOS, and macOS breaks a bunch of APIs every year. But macOS users also buy expensive recurring subscriptions for every app they use, so Mac software companies can afford to employ developers to clean up after Apple every year. Linux doesn't have that; a lot of Linux software is either unmaintained or maintained by volunteer developers in their spare time.