Annoyances I've found so far:

1. make-iso9660-image.nix and make-tarball.nix both support contents, to dump arbitrary other files to the resulting filesystem. make-disk-image.nix does not. Furthermore, the way contents is implemented varies across related scripts: make-etc.sh has a very similar structure, but understands glob patterns, UIDs, GIDs, and modes. The two mentioned earlier are stripped-down versions of the same idea, with no support for UIDs or GIDs.
2. There's plenty of code copied and pasted between the various builders. For example, search for "!!! should use XML".
3. There are some cool building blocks like make-ext4-fs.nix, but not all image building scripts use them, and they can likely be implemented more efficiently
4. Some builders register the paths in the Nix database at boot time and others register it statically in the image/tarball

This is a more logical breakdown to me:

1. Have a set of builder functions that know how to take a filesystem tree on the builder to a disk image, possibly partitioned, possibly with bootloaders, and with different target filesystem options
2. Have another builder that knows how to make a tarball of a system tree
3. Have some logic that knows how to take a NixOS config (and optional additional files, like contents above) to a filesystem tree
4. A set of idiosyncratic NixOS configuration modules for individual providers (EC2, GCE, ARM systems, etc.)

I'd bet that virtually of our tarball/image/nixos-install work can then be expressed in terms of those four building blocks.

I'm volunteering to clean this all up. #23026 and #21943 are the first steps, but I plan to reduce all the sprawl as well. I think our image building story can be truly excellent and a major selling point of NixOS, but right now it's inconsistent and occasionally pretty awkward.