I think it’s cool that you figured out how to do this 
Some notes though.
generationsDir.copyKernels = true; is for a different boot mechanism, so that’s not doing anything at all.
${pkgs.coreutils}/bin/cp -r /boot/efis/efi1/* /boot/efis/efi2 that’s only copying files to the new location, not deleting obsolete generations, so these will just fill up. Might want to look into rsync and its various features to fix that.
It also copies loader/random-seed, which is not good practice. That file is updated every boot by systemd-boot, and its old values should never be reused. As is, if you boot one and then the other without a nixos-rebuild in between, you’ll end up reusing the seed. This is one of the reasons we haven’t implemented mirroredBoots for systemd-boot yet. Arguably the right way to do it is to instantiate and run the systemd-boot-builder.py script once for each ESP, so they aren’t literal mirrors of each other; and that’s just more complicated.
See, I knew there were smarter ways to do this! Thanks, this helps a lot.
I’ll think about the loader/random-seed issue… I remember seeing a discussion about this I believe on the mirroredBoots PR.
I’m curious about the benefit of this for the EFI partition, the last time I was messing with this it was about using one EFI partition for RAID1 with two root partitions with the same data.
Mirrored boot devices are already available in the form of hardware RAID 1 cards that perform dumb block-level mirroring on multiple mediums. In other words, if one fails, you’ll still be able to boot your server, and you get a nice fast L2ARC space for ZFS (or else just a fast NVMe drive) as a bonus. This is setting up a similar thing in software.
@ahoneybun yeah the typical set up I’ve encountered is data in some kind of raid configuration, so on drive failure or bit rot, your data integrity is maintained – the boot partition and maybe the os in general is on a separate, non-mirrored drive, maybe a fast SSD whereas the data is on spinning rust.
But, your boot drive and OS is not similarly protected. ZFS-on-root theoretically provides a level of protection for the OS, but the system still needs to be able to find a working EFI partition to boot – if the whole drive that had your one EFI partition goes belly up, you have to find some other way to rescue your data.
Not an problem if your computer is right next to you, but if you want to manage it remotely, some additional safeguards would be nice. This is that attempt.