What made Android successful is Google seeing that mess and creating an entirely new operating system, from kernel to especially userspace. Android in a way turns Linux into a system that is much closer to a microkernel based OS. The binder IPC on the kernel side resembles the message passing systems of microkernels and almost all communication, except a couple of system stuff, passes through it. From allocating display buffers to "Share" buttons all of them uses this system. It has nothing to do with classical desktop system nor the Unix "way" of doing things, which is oversimplifying the system layer to the point of almost uselessness.
While the build system of AOSP and Android apps gives me shivers, the OS works beautifully and it can be continuously upgraded and be kept secure, if greedy SoC and device manufacturers released driver updates.
Only OEMs have the ability to directly use Linux, doing so from userspace means using what Google considers as being private APIs.
Not to mention that Google could at any moment change it by Zircon, if they could so feel inclined.
So Android is hardly the best that Linux could make it as desktop.
[0] - Native Development Kit/Android Game Kit
Chrome OS Flex might be interesting when it does, eventually, support the linux environments.
glibc is quite good about ABI compatibility - not any worse than Win32.
X11 also has a stable protocol. Even with Wayland there is Xwayland for backwards compatibility.
OpenGL and Vulkan have stable ABIs.
Your program location doesn't matter - unless you are installed via the package manager (in which case the package specifies the location) you can load everything relative to the binary.
User config location is gained a new standard for where you should put things to not mess up the home directory but that does not break anything. Old programs can still write to ~/.yourfancydotfile.
Evenvironment variables only matter if you wrote your program for them to matter.
Preinstalled libraries are irrelevant - ship your own like you have to do on windows for anything that is not part of the base system.
Acceptable keyboars shortcuts and standard dialogs are integration concerns and not strictly needed. Not saying that you shouldn't provide DE-integration where that makes sense but that can be done on top of sane fallbacks. Also, there is now a cross-DE API for standard file dialogs: xdg-desktop-portals
.desktop files have been standardized for a long time so you should not have problems registering file types - it is of course up to the DE to manage the default and that is a good thing.