As far as I know, X has many issues with things like multiple monitors, full-screen programs, low-latency input etc. Not sure if Pulseaudio similarly has issues with things like surround-sound systems that a game uses more in-depth.
If both monitors have similar configuration (DPI, refresh rate) it is fine (Xrandr fixed many of the issues that X previously had). If the monitors have different configurations it isn't, but this problem will reflect even on the desktop and I am sure that nobody will report a problem that they have on desktop as a "game bug".
> full-screen programs
X doesn't have a concept of full-screen, but anyway, it mostly works fine if you grab the root window (that of course you shouldn't write code manually to do this, your game engine probably will do it for you automatically).
> low-latency input
X latency is fine for most games, and in many cases you will not use X to handle input anyway. Also, if your game really needs low-latency (only a minorit of genres do), you can bypass X.
Anyway, I was not referring to specific X or PulseAudio problems that you will if you put things on container or not. I am just saying that even if steam-runtime doesn't built-in those libraries it is not much of a problem since those APIs are stable.
You said that 'as long as it runs in the Steam Runtime, you don't need to worry about the host distribution', and I was pointing out that you'll still communicate a lot with the host distribution. For example, someone could be running a distribution that ships with some ancient copy of X, or Pulseaudio, and that would cause problems for your game even if it is running in a container.
Even on Windows you wouldn't release a game that works on Windows older than 10 nowadays, you can assume a reasonable up-to-date distro. I am quite sure Steam Runtime works at least as far back Ubuntu 16.04, the oldest distro that I can think someone would want to run Steam on it.
