No the discussions, development and trials were firmly aimed at the emonSD. Some of the discussions are quite long and indepth so they can make things sound overly complex. The sticking point seems to be that to make “it simpler” it is believed we should just create new files and folders each boot as it’s not so complex in principle, but that’s actually quite hard to manage (by comparison). By simply keeping a persisted copy of the logfiles held in RAM, every hour and at shutdown, it eliminates all the issues. So what sounds like a complex arrangement (managing 2 copies etc) is actually far, far simpler to setup, manage and it provides the additional benefit of keeping the logs even when users (understandably) react to an issue with an immediate reboot (currently all useful info is lost until it happens again).
My minor mods then also use logrotate to shift rotated logs out of ram and are only held on disc, thus freeing up ram, we do not need rotated and compressed logs in RAM.
Since it is a mirror image that’s persisted each hour, even if you install contraband softwares, the original install instructions will work fine, no amendments needed due to our logfiles being in ram. if a guide says create a folder in /var/log, that’s exactly what you do, even a package manager (apt-get) can install as per usual, as long as the host doesn’t crash before the hourly backup or a graceful reboot, the new logs will be persisted and then copied back to ram on start up, no hardcoded lists, no files to edit with new software, it all works transparently.
Some will raise concern about boot up speed, but all log2ram is doing is reading the logfiles to RAM, not writing anything to disc so it is quite quick, certainly no slower than restarting all the services in rc.local with a few seconds sleep in the midddle 
.
I’ve had it running on a test setup for a while with no issue, but I have not stress tested it in great depth with lots of traffic etc. I have my own RO RPi’s that are stable (that do not use rc.local like the emonSD either) so I do not want to change them unnecessarily. We could test it further if there was interest, but I’m just wary of sinking even more time into something I don’t necessarily need to change and no one else wants to change.
[edit - Some bedtime reading material 
]
An earlier, longer more complex discussion
A more recent discussion where Glyn showed some interest, but it did start looking a bit more complex.
The log2ram repo is at GitHub - azlux/log2ram: ramlog like for systemd (Put log into a ram folder) and my minor changes were these
Comparing azlux:master...pb66:pb66 · azlux/log2ram · GitHub. This could be installed (and uninstalled) with a one liner command with some minor edits, eg the script can be saved as an executable on github, so if we pull and execute rather than downloading a zip and use chmod etc etc.