> Because nix is not fully reproducible, full source bootstrapped, or multisigned.
You've conflated Nix and Nixpkgs. My suggestion was to use Nix as your build engine, not to base your system on the existing packages in Nixpkgs. You'd still build your own complete package set, like you're doing already. Using Nix would give you a build sandbox that is purpose-built for deterministic builds, and you won't have to work around the troubles of Docker, which is not designed for that. I'm sure you must be aware that it's effectively impossible to reproduce a Docker image bit-for-bit when building from a regular Dockerfile, and I'm sure you've had to come up with some nasty hacks to work around all that. You could also use Nix's built-in store path signing feature, which does support multiple signatures.
Docker, Kaniko, Buildah, and Podman can all produce bit for bit reproducible OCI images without any hacks for more than a year now. (Docker itself was last to the party here)
I do not think we gain anything using the nix format, but we would lose a lot of compatibility with the huge ecosystem of container-native build systems and infrastructure.
Entirely different threat model.
The OCI spec supports multisig, multiple build engines, multiple registry engines, which are a major benefit of using standards.
You can even both build and export to OCI images with shell scripts.