You'd want to be using old Nixpkgs definitions as a starting point for importing a package definition that will work with a package's build system at the given version, and trying to rebuild it against the libs that are already in your environment.

You could do the same basic versioned dependency solving all the way down your dependency tree using the same tool, whenever one of the recipes expected a version not in your current environment.

That's what it would mean to incorporate real dependency solving into Nix/Nixpkgs. I don't think you'd want packages in Nixpkgs' top-level/all-packages to rely on that feature, but you could have it be there for devs who want to build out bespoke environments but rely on the collective wisdom about how to build this and that at such-and-such version currently encoded in the history of Nixpkgs.

Sometimes you couldn't be offered a solution that you're confident would work— this kind of thing would be a starting point for maintainers of complex environments. But it would make porting old versions forward to a newer env easier just by helping automate that process of digging for examples in the history of Nixpkgs.

I might just lack imagination, but I think the wheels are already well in motion for at least one significant piece, which is many more upstream maintainers having some awareness of Nix and Guix (and now Tea too, I guess) and understanding the value of things like reproducibility, relocateability, not accessing the network during build, not making assumptions about where stuff will be located or that the different build outputs (lib/bin, dev, doc, whatever) may end up in fully separate trees. This goes doubly so for tools maintainers like the people at Kitware, who wield an enormous amount of power in steering devs toward patterns that allow software to be packaged for Nix with minimal patching.

All this lowers the fragility of the package definition and I think helps increase the likelihood of that software being forward- and backward-compatible with different versions of its underlying dependency pool.