I’ll be able to test it in a few hours.
I was expecting that I would still need the service to initialize the external clock, that this would only stop the need to modify the /boot directory.
Unless the best way is to use an overlay to activate the external clock, not a service?
Oh year you are right, the I2C device still needs to be created. I am no I2C expert, not sure whether the device generation can be enforced via device tree (overlay), or otherwise a udev rule works best.
However, the external RTC should now appear as /dev/rtc0 (after the I2C device is created), and the kernel should apply it automatically then, like it does now with the faulty embedded RTC.
So yeah, your service is still needed, but dtc not anymore.
Btw, does fake-hwclock cause any issues? It does not move the clock backwards, but maybe similarly to the embedded RTC, the external RTC is set to the system clock, when fake-hwclock runs first? Of course it is at least unnecessary, so makes sense to purge it, but I wonder whether it must be purged to assure proper RTC operation.
It can be, that is primarily how various devices are added to Raspberry’s product line,
sudo echo "dtoverlay=i2c-rtc,ds3231" >> /boot/firmware/config.txt
Also why we needed to kill the existing RTC using the device-tree. You know more about the device-tree than I do though.. First time I messed with the device-tree topic was above.
May try grabbing the i2c-rtc.dtbo file from Raspbian and seeing if it can be adapted, then all the clocks may work. I’m kinda starting to understand how they work. 
I don’t think so but honestly I don’t know for sure.. I am pretty sure it isn’t needed at all, on any system, RTC or not. I can see its use if the SBC does not have a RTC with battery and is without a network connection.
Some of the how-to guides said to remove, not purge and then edit some of the configuration files left behind, which didn’t make immediate sense to me, but other software may check for their existence. I didn’t want files I wasn’t aware of to mess with what I was trying to accomplish so purging it made the most sense to me.
I was only looking at the various rtc devices, I didn’t look at the effect it had or even when it was loaded.
I was hoping that fake-hwclock was included by default in Diet-Pi for a reason..
Yes, the new device-tree files work with without needing modification. The internal RTC does not appear when using them as-is.
Looks like it is just adding a child device to the I2C bus device node in device tree:
Should be possible on per-SoC basis for other SBCs as well.
For early boot timestamps only, and only if systemd-timesyncd is not in daemon mode, else it does the very same thing.
But this can be relevant if e.g. DNSSEC is used or otherwise parts of network bootstrap depend on certificates with validity dates. Otherwise even the connection to the NTP server may fail, if e.g. DNS resolving fails. One of the reason I generally do not recommend to use a local recursive DNS resolver like Unbound for a server system itself, unless there are particular reasons to do this.
And for debugging, early boot timestamps can be relevant as well. Else it can be difficult to distinguish boot sessions in logs etc.
Yes, there are cases it can be helpful.
Systems can very easily be powered off for that period of time too, fresh installs use images with old files.
Environment=SYSTEMD_NSS_RESOLVE_VALIDATE=0
Fixes timesyncd, so it won’t require DNSSEC to pass, it is a chicken-egg issue. Can’t validate DNS because the system time is incorrect, can’t set the time because DNS won’t validate.
Otherwise, this is off-topic.
On a fresh install however one usually has no local recursive DNS resolver configured. And when running such, like Unbound, leaving the system off for months or years (the manufacturer timestamp of the embedded RTC is from 2020), it is pretty much expected that you need to bootstrap it manually once, if not for the timestamp, then probably for DNS root hints and anchor keys.
fake-hwclock stores the current time once an hour, systemd-timesyncd by default every 5 minutes (though as metadata only, which can be kept in memory longer depending on mount and journal options), which mitigates all related issues very effectively even on a system crash.
Oh? Isn’t setting up a local IP and upstream DNS server (often DHCP but static IPs are used too) the minimum network configuration that gets done on any networked system?
Maybe a misunderstanding. Point was to not use Unbound, AGH or PiHole as recursive local DNS server for the server system itself.
Right, I mean recursive and validating DNS resolvers like Unbound:
x.debian.pool.ntp.org and hence fails to sync the system clock because the clock is off 
.But normal local DNS resolvers like libc do not query DNS root servers and cannot do DNSSEC validation, but rely on external providers to do so, like from your ISP, Cloudflare, Google DNS or whatever. So no problem on first boot, but only when installing a recursive resolver, and when using it for its own host as well (which is why I generally do not recommend that).