Official Proton support is an excellent, functional compromise.

Except it’s not a compromise. 99% of games on Steam work on Proton without input from the devs. All they have to do to make it work on Proton is to not go out of their way to break it. At most, they probably have a single Linux system in the studio to run builds on just to make sure it works.

They’re doing nothing in this regard and pretending they’re doing something for brownie points. If you don’t want to put in effort to make a separate Linux native version that’s fine, but don’t then turn around and claim that you’re focussed on Linux support.

It’s usable until it isn’t. That’s the problem with Wine/Proton. It’s not a stable implementation of a well defined specification like Java. It’s a reimplementation via reverse engineering of proprietary Win32, something that’s buggy and sometimes changed between Windows updates by accident.

Update to a game compiled with a slightly newer version of Visual Studio, like it’s happening all the time with live service games? Compatibility becomes a dice roll. Sure, the chance is high that compatibility is kept but it not 100%. Neither is Proton not breaking a game by accident. The big games are automatically checked by Valve but some weird indie game isn’t.

And here comes the wonderful thing that’s Steam Linux Runtime: containerized binary compatible runtimes of every other or so Debian release. All the issues about not being able to target Linux because of its ever changing nature have been fixed by Valve and yet for whatever reason Valve refuses to promote it towards developers.

They literally promote Win32+x86 emulation for Steam Frame development, a wearable platform where even the slightest stuttering can cause motion sickness and where battery optimization is paramount.

I hope Valve bring Lepton, their Android compatibility layer, to x86 Linux as well. Lepton is based directly on AOSP and not reverse engineering. I have higher hope for that.