The problem space is the same but there is not just one valid approach, even when we both decide on sticking to functional package management.
I love Scheme, so working on Guix is a no-brainer for me, but also other decisions of the Guix project align more with my priorities, such as the desire to not let blobs (e.g. for bootstrapping Java) sneak in needlessly. The absence of non-free software is a feature, in my opinion.
Technically, I don't see it as "duplicating" Nix: Guix uses low-level parts of Nix that are awesome, and replaces higher-level layers with a more integrated and unified system. See https://arxiv.org/abs/1305.4584 for the technical rationale or the video on the home page on the concrete impact of those differences. Hacking GuixSD is a very different experience, I think!
(Disclaimer: I maintain Guix and I'm a former NixOS hacker.)
If I were to start thinking more seriously about the wasted effort in duplicated definitions of packages, I would probably end up thinking about using RDF linked data to define software dependencies and capabilities. Then you could generate Nix expressions, Guix things, RPMs, Docker containers, or what have you. The declarative model of Nix/Guix should work well with something like that.