Yes, this is what I am arguing you should do, by overriding its source to that version (which I described as being easy).
You should not try to pull in a version of nixpkgs (whole OS) that has X.Y.Z, and combine it with another version of nixpkgs (whole OS) that has some other library's version A.B.C.
In the same way as you don't try to combine 3 different versions of Debian to get specific versions of 3 different Python libraries.
Concrete example:
Current nixpkgs has libpng-1.3 and libjpeg-4.6. For building your app you desire libpng-1.2.3 and libjpeg-4.5.6.
To get them, you use the current nixpkgs, and override `libpng` and `libjpeg` to the versions you want using e.g. `libpng.override { src = fetchGit ... }`. You do NOT do `libpng = (import <older-nixpkgs-version-1> {})` and `libjpeg = (import <older-nixpkgs-version-2> {})`. Because that way you will also end up with 3 different versions of e.g. `glibc`, which may be incompatible.
I hope this clarifies it!
How to find out what versions of `libpng` are available to be used in `shell.nix` or `shell.flake` with nix tools?
It's very common to pin dependencies to specific versions. And upgrade them carefully, also to specific versions.
If I use a dependency at version X.Y, a vulnerability is discovered in it, and fixed in version X.Y.Z, I don't want to "start from base nixpkgs". I want to upgrade that specific dependency to a very specific version.
From how you described it, it's either not possible or extremely cumbersome to do with nix. Which begs the question: what's the point?