Any step forward here is good, but the main problem remains: the number of ports takes precedence over basically any other consideration by some long-time members (including the DFL), and the project suffers. You can see some of this madness laid out in the page you linked:
1. Testing subsets of C++11 on platforms that no users actually use (again, I did the analysis and presented the data in 2017);
2. Testing compilers for ports that are already dead and have had no new ScummVM releases since 2015;
3. Testing for C++11 features on unsalvageable binary-only compilers from 2003.
I actually did a whole lot of work to try to bridge the gap and satisfy everyone. I rewrote the CI system, created about a dozen Docker images with up-to-date compilers, and modified the `configure` script so that individual engines could opt in to using newer language features while old engines and backends could continue to build so people could keep their ‘trophy’ ports. I proposed a new release policy where builds would be automated (instead of the current situation where random people are individually responsible for manually creating and uploading binaries), and it would be the responsibility of porters to make Docker images with functioning build environments to hook into the new build system. This all seemed very rational and would’ve solved a lot of problems, but it never happened, at least in part because the guy who does nothing except build the Dreamcast binaries refuses to own an x86 computer because he thinks the ISA sucks and so would have had some trouble making the image to automate the build.
Obviously any passion project run by volunteers doesn’t have to follow trends or even care what their users think, but it’s clear that ScummVM holds a unique and important place in software preservation, so merits a little more care and thoughtful stewardship. I think that it (and its users) deserve more than they get when folks hold up “number of ports” as a critical metric and then use it to block important changes that would significantly improve the project in every other way.
Believe it or not, there's finally some progress here!
https://wiki.scummvm.org/index.php?title=Compiling_ScummVM/C...
Even the Dreamcast port has a version of GCC able to pass the initial standards tests, so most legacy ports seem to be in a state that they'll be able to leverage at least a subset of C++11 functionality.
(Sadly - as with many large community-driven projects that require a specialist set of skills like reverse engineering - ScummVM does have a slight history of alienating contributors only to adopt the point in contention as some point in the future.
Source: I was once a co-lead developer for ScummVM, and tried unsuccessfully to fix this :P)