First of all, Linus Torvalds, thank you a lot to take the time to reply.

On your remark: Both binaries and source code from decades ago are supposed to still "JustWork(tm)"

I would really like to agree, but, like you also said, the entire Linux stack is build on a very shaky eco-system, where backwards compatibility seems to be the least concern:
* C++ the language which is widely used to program services and applications in Linux, is a nuisance when it comes to binary (and even code) compatibility. As soon as you change the compiler version, linking will fail because of those mangled names. This was ameliorated in the last compiler versions, but only recently.
* the Linux libraries currently form a hell which is worse than on Windows. If you take a package or binary library and try to install it manually, it will fail 100%. So there is no way except to get the official package for that distribution or to manually compile from sources.
* even inside the same Linux distribution (eg: Ubuntu) between consecutive recent versions (16.04 and 18.04) there is little chance of running the same binary code. And if you try to compile something, it fails if you depend on anything else that libraries that are dormant (forgotten) for decades. And the old libraries you cannot compile as they depend on software that was not brought up to date.

On Windows, the end product is indeed managing to run old binary code (running code and binaries from the 90's on Windows 10, with MFC and all the old stuff). But in Linux, the eco-system crushed backwards compatibility many years ago. So, the Linux 'product' is not loved because backwards compatibility, it is hated for the lack of it.

So, even if it was cool to be backwards compatible years ago (and is cool today if the product does it), why bother with it so much now when the entire eco-system is going the opposite direction?
And again, why not at least deprecate now stuff that became meaningless 10 years ago so that in 20 years, when we use quantum computers we don't stumble on sched_yield again (joke).

Regarding porting programs from Windows and UNIX
First, there is no more stringent need to port stuff from Windows as most devs use their free time to write new apps on mobile platforms. And if we really need to port some important program, we can use docker-like technologies which are suitable for all these backwards compatible hacks.
Secondly, all the programs that were 'blindly'(read 'easily') ported, which are using API's changed under the hood, even if they were ok when they were written, are now full of security loop-holes because they no longer understand what goes on under them. In the last 20 years, had there been pressure to improve C and deprecate its unsafe functions, the whole world would be safer. With the risk of being called an Apple fan-boy, I give Apple credit for having the guts to stick to a better language when it comes for all library and application usage. Today they are nearly unbreakable, while Linux and Android are punctured easily.

Regarding the kernel itself
C is still a great language, but why keep it dormant for so many years? It compiles on all platforms, this is true, but it needs so little to become safer to use. Just add some form of shared and weak pointers, and safe string functions, start to use them, deprecate old ones and you eliminate half of the kernel's vulnerabilities and make it more reliable. The Linux kernel is the main user of this language, so it must have a say in requesting some new features. So why keep it so primitive? Soon it might be too late to change..
And we all know that what the Linux kernel adopts, everybody adopts in a few years. It could improve the lives of many C programmers like myself to have something new but relevant (unlike C++ new versions which are new and full of irrelevant language features).

It is indeed all about philosophy but I still say that the lack of action and the prevention of visible changes for the user don't do anything good in Linux, or any other project (except for the increased complexity which helps feed Linux consultants, which might not be all a bad thing).

Thank you again and again for your precious time, and best regards,
Alex Smeu