After quite a bit of trial and error, the latest version of Blender that can run through blender-softwaregl in the above mentioned configuration is 2.79.
There is nothing in the changelog of 2.79 or 2.80 to indicate any sort of reason for this.
Update:
The short answer seems to be that it is impossible to run Blender 2.80 over XDMCP in the described setup.
The longer answer is that Blender makes use of an X11 extension that is only effective when both the "client" and the "server" are running on the same machine.
In the client-server architecture, a process connects to another process and asks it to carry out tasks for it. This communication is governed by a strict "language" (the protocol). Usually, you don't think twice about who is the "client" and who is the "server". For example, internet browsers are clients to web servers and they exchange information over HTTP.
In the X Window System, the machine that should be considered as "the server", is the machine that shares its resources. As there can be only one mouse, keyboard, actual video output and so on, the server is the one process that "talks to them" and manages access of other processes.
This is where it might get a bit confusing. The typical way by which access is gained to a remote machine is through a Secure Shell connection.
This implies that the machine we are trying to connect to is running a Secure Shell Server and the connection is initiated by a Secure Shell client such as ssh in Linux or putty in Windows and others.
After authentication, we might try to start an application with a Graphical User Interface.
To do this, in this setup, the computer that executes the SSH client, needs to also be running an X11 server (the machine that provides the actual resources is not the one that is running the SSH server / Blender).
So, the complete round trip starts with the SSH Client (e.g. putty), connecting to the SSH Server, the user starts a piece of software (e.g. Blender) that uses the X Window Manager, it, in turn attempts to connect to a "display" server and initiates a connection back to the X Server that runs on the same machine that initiated the SSH connection (e.g. to something like XMing).
The end result of this is that the client process (Blender) does not run in the same memory space as the server process.
The MIT-SHM extension is an interprocess communication mechanism for the two communicating processes to share large amounts of memory.
When the extension is supported, the client might reserve a memory space through a "special" set of calls which ensures that another process (the X Server) has access to it too. This is to make the main connection less data heavy (and therefore faster). Instead of sending a huge amount of data over the connection, the processes might simply exchange the "handle" of the memory space which is just a number.
This makes sense for a heavy application such as Blender.
The XMing server does not support the MIT-SHM extension. This is the reason behind this specific error.
Even if the XMing did support the MIT-SHM, the client and server processes would run in different memory spaces and therefore this "handle" from one machine would not make sense to a different machine. This is why it is impossible to run Blender 2.80 under this setup.
Any attempt to force that feature off or circuimvent it would imply getting data from one machine to the other via the network (in one or another form), at which point, it would probably be equivalent to running Blender via VNC (if you can) where everything runs on the remote machine and the output is streamed back to the local machine.
Hope this helps.
Notes:
An X Server and an X Client are communicating via XDMCP
There are a few ways of trying to circumvent this MIT-SHM "limitation", but they basically imply running an X Server at the remote machine at which point, that remote machine would have to handle software rendering for Blender and streaming of the output. This is outside my use case and have not looked into it further but you are probably better trying to do this via a VNC type solution (if you can) rather than trying to "re-wire" X.
- I don't know if there are ways to solve this via Distributed Shared Memory in Linux, but again even if it was possible (without starting a local X Server), the data that are supposed to be travelling between the two processes via the MIT-SHM would now have to travel over the network which, in the case of remote machines, is not going to happen faster than a VNC type connection.
