yeah, I kind of know vulkan is picky since it is very close to the hardware, the hard lockup is never far away, and better use it in a very conservative way, no fancy stuff.

Aside of this, there is also the distribution of binaries with best compat across linux based OSes. For instance, with GNU symbol versioning and IBM/redhat symbol version frenzy, 1.5 year old glibc distros won't run games built with a today glibc (aka shooting linux gaming in the foot).

The idea is to iron out such issues: - pure ELF64 set of binaries, namely does not use main(), but the hw ABI entry point (on linux/sysv this is almost a straight main()). Manual linking of the game binaries (don't rely on the compiler driver default objects). - all distributed binaries should "libdl" everything they need from the system, including the libc. It means only libdl should be in the ELF static loading section (except the distributed SOs), and all binaries should have only dlopen/dlsym/dlclose undefined symbols in the ELF dynamic section (except the symbols from the distributed SOs). - don't use ELF symbol based TLS (Thread Local Storage), but pthread TLS, because ELF symbol based TLS is nasty (would need to parse the ELF headers to get some offsets then call the ELF ABI TLS func to resolve to the TLS variable). - static link as many as possible "libdl-ized" third party libs, and yes, this include a libdl-ized fork of the static c++ runtime you use, since godot is c++. - wayland(libxkbcommon)->x11(libxkbcommon-x11/xcb) fallback - vulkan->GL(->CPU) fallback - libasound only (pipewire/pulseaudio will be hidden behind the alsa API if there, and it could be dmix/dsnoop). - joystick support directly via /dev evdev devices, and hotplug with direct kernel netlink event (avoid like hell udev) or inotify or polling the /dev/input directory.

If this work, distributed binaries should be rock solid in time and across many types of linux based OSes (even musl lib one, in theory).