This affects native Steam too in case where distro has SDL 2.0.10 (which was released this Summer) so for those this is pretty much a time bomb. For Flatpak we can workaround, native will just break unless you fix pinning.

You should either remove pinning for libSDL

I would personally say this is the answer. If a distro's SDL2 is newer than the one in the Steam Runtime, pinning the one in the Steam Runtime will potentially break anything that came from the distro and has SDL2 somewhere in its dependency chain - the SDL2_foo family of libraries are an obvious example, but not necessarily the only one.

Pinning libraries to the Steam Runtime version is quite a big hammer, and we should ideally only use it in cases where there are known to be incompatibilities, like libcurl.so.4 (where the version in the Steam Runtime came from a time where Debian/Ubuntu had versioned symbols that were incompatible with everyone else's).

you end up loading libSDL-image 2.0.10

The versions of SDL2 and SDL2_image are out of sync (they're separate upstream source releases, with SDL2_image currently at 2.0.5), so more precisely this should have said:

You end up loading a version of libSDL_image that was compiled against (and hence depends on) SDL2 2.0.10

The practical effect is the same though.

A fix is in progress, removing the special pinning for SDL2 so that it follows the same logic as most other libraries (use the Steam Runtime version or the distro version, whichever one looks newer).

Fix will be in the next beta update (> Sep 20).

There's some reports from users that the fix helped with games that do not have our workaround. I requested test results directly here but anyway.

Since this is pending in beta, Flatpak Steam will now block SDL2 2.0.9 (and only that version) from loading from Steam Runtime effective for all games. It will be clearly visible from logs when this happens so we should be able to know when above fix lands.