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.