From my vantage point, it certainly seems successful. I finally ditched my Windows gaming-only PC last year. Granted, people like me are likely less than a single digit percentage of gamers, but we exist, and as Proton compatibility improves, the percentage could rise.
I usually ask their devs to use the '-static-libstdc++' gcc/clang option (and at the same time -static-libgcc), and this issue is gone... actually partially, because the static libstdc++ is not libdl-ing its system (module/version)s & (symbol/version)s (well, did not check if c++ gcc/clang devs did fix that) and this is a big problem too: the linker with use the most recent version of modules and symbols (and you cannot overide than unless properly using libdl with dlopen/dlsym/dlclose).
What is the problem with that: well, the game binaries will then refuse to load on system with glibc modules/symbols with "too old" versions... and I was hit hard with this: no more than 1.5 years... yep, this is filthy nasty. And yes, this is not limited to the static libstdc++, it encompasses the glibc modules too. Godot devs mitigate this by explicitely warning devs about this issue and provide some containers with a really old glibc in order to avoid too recent versions.
When you really look at this, I mean with a "final" perspective: the "right" way would be to eat the bullet, and I mean seriously: deprecate ELF DT_NEEDED (and static TLS). It means that if you want to get some services from the system shared objects, you must use dlopen/dlsym/dlclose (and deal with the versions). It would be those symbols will become hard defined in the ELF loader, like __get_tls_addr() for TLS.
We could manage to keep DT_NEEDED, but it means binutils ld MUST allow fine-grained version specification of modules(shared objects) and symbols... which it does not (or it was fixed very recently and I missed it, or I sucked and did miss it from the doc for years).
You cannot "officially" remove any symbol versions, but it does not matter: games must become pure ELF binaries, namely MUST NOT USE main() for the following reason:
A genius at IBM(redhat/sourceware) did break for good the glibc: From glibc 2.34 __libc_start_main symbol has 2 versions, GLIBC_2.2.5 and GLIBC_2.34, it means that any game exe linked against glibc 2.34 won't load on system with glibc below 2.34, if using main().
wow... those guys are msft "grade" in planned obsolescence.
It's probably a ridiculous figure. However, compared to the amount Sony/Nintendo/Microsoft spends engineering their console runtimes, I bet it makes a lot more sense. It also helps that Valve doesn't have to maintain Wine by themselves, with various cross-platform stakeholders funding and making contributions. It's obvious that Proton/DXVK/Wine is a passion project for Valve, but much harder to tell if they're seriously threatening the idea of a "Windows runtime".
> Elephant is the room: c++ is not mean for binary-only games
I think I agree with you. Steam's runtime provides a lot of stuff (probably standardized libstdc++), so it's hard to truly evaluate how true this is. That being said... both Steam and Wine do a really good job juggling it. Steam works roughly the same on NixOS, Arch, Flatpak and Snap - that's a better starting point than most software clients get.