Its a fix that potentially gives duplicate library names in "/opt/vc/lib" and "/usr/lib/arm-linux-gnueabihf/" (which was the case in Jessie) so the best fix is to compile the programs with correct unique library names.

Probably not, but there are people that do not agree either. Its not uncommon for developers to update their software to support newer versions of OS. And its not like its a huge job.

It is not a quick job if you consider compatibility with others ARM boards which are more conventional for their GLES library name... even doing it in the "dirty way" (so breaking compatibility) would needs months before all developers do it (if they even care)...
Moreover i would not say theses modifications are needed for newer version of OS but for specific board (raspberry here). I mean debian stretch on others ARM boards doesn't have this issue, this is purely a raspberry choice breaking general GLES consensus ... so we are going another step further with specificity regarding GLES on raspberry which is not going in the good way in my opinions...

IMO having libraries with duplicate names are a worse solution, which was the case in Jessie.
Having unique names should make the transition easier when we get to the next big Raspbian release.

I may agree with your opinion on the Mesa libraries but I don't have the complete picture and the accelerated OpenGL drivers are still in testing. So having software OpenGL rendering should make more software packages work out of the box.

Yes but here we are talking about GLES which is a standardized interface, hence the SOC specificities should not interfere in this case (it's a pity that's even without this point it's already not true )...

They're not compatible/interchangeable libraries. The source code of existing applications needs to be modified in order to use libbrcmGLESv2.so. 99.999% of software that links against libGLESv2.so won't work on the pi. Likewise, software written specifically for raspberry pi won't work with libGLESv2.so.

So we were in the situation that the only thing distinguishing these incompatible libraries was their path. Some software intended to work with the mesa driver would pick up the wrong library and fail and the same goes the other way. Software has no reliable way of knowing which library will be available on the system. With the accelerate open source drivers, the previously mentioned 99.999% of software actually has a chance of running and there's a clear distinction between the libraries. You can install neverball from the apt repo and it will just work without having to modify the source code. That's the direction we would like to move in.

Here's an approach to run those three GameMaker games (Maldita Castilla, Super Crate Box, They Need to Be Fed).

1. If you've enabled the OpenGL driver on Stretch, disable the overlay by editing /boot/config.txt to comment out dtoverlay=vc4-kms-v3d, then reboot.
2. Then run any of these apps the same way the Minecraft Pi wrapper script does. For example:

Although this will put your system into a state lacking full OpenGL (and thus unable to run other games like Minecraft Java Edition), you can just as easily flip it back. I haven't tried littlecrane-rpi, but this might work there as well.

edit: However the two SDL2 Webfoot games (CubixMania and Air Hockey Arcade) with their modified SDL2 seem to attempt to load /opt/vc/lib/libGLESv2.so regardless (as revealed via strace). This is resolved with a subset of topguy's recommendation:

It would be cool to have Mesa EGL wrappers for the other apps too. Over time the Mesa driver could achieve performance that exceeds that of the old closed-source brcm one and we'd benefit even if the authors never update their software. It's no small task to support a LD_PRELOAD library like mcrpi-wrapper, but I do believe it to be possible in all these cases. I've written more about that elsewhere: