Just as a quick heads up: I'm considering switching the whole system away from the bare metal environment to a Linux-based system. That would of course be increasingly distant from the original vision, but it has so incredibly big upsides that I think it might just be worth it.
I currently have a port of the SDL version to SDL2 that runs on Linux on the OPi Lite using SDL's kmsdrm driver. After some tweaks for performance it runs really well. Of course a lot of support for various things is missing, so it's currently an inferior experience compared to the existing version. (I intend to implement joystick support next, which should work much better than on the existing system.)
A lot of things that would be extremely difficult on the bare metal platform are near-trivial on a Linux-based system. Like mounting remote file systems. Others would at least become orders of magnitude easier, such as porting to new SBCs, WiFi, 3D support, multithreading etc. Having a properly functioning OS makes developing a lot easier as well. No file systems or binary loaders to debug. (Not to mention that being able to run Linux programs in Engine BASIC's existing ANSI terminal emulation might finally get the people complaining about editors off my back...)
I'm not sure how to mitigate the downsides yet, though. Direct hardware access would technically be possible, but would probably not yield the desired results because the kernel would interfere. (For poking around in memory it would probably be acceptable to require the user MMAP any memory they would want to use first.)
Also, with the bare metal system I have sidestepped the issue of board support by either always assuming that a device is there when it won't do any harm (USB, Ethernet, analog audio, TV out), and simply not supporting it when it would (voltage regulators, eMMC). The Linux kernel supports more or less everything, and thus needs an appropriate device tree binary to work correctly. There is no reliable way to detect which board we're running on at boot time, so the correct DTB has to be put in place manually by somebody. And I don't feel like hosting several (potentially dozens) of nightly multi-megabyte SD images...
All that said, it works way too well already to not pursue that path, and I'd be surprised if I found a roadblock that would be so big that it would make it nonviable...