Question about using multiple nixpkgs pinned versions in automation and bloat

Consider a use case where we are:

• installing, with nix, multiple tools for our development environment
• pinning nixpkgs as described in https://nix.dev/tutorials/towards-reproducibility-pinning-nixpkgs .
• using this same nix setup in our automation (e.g. CI or CD, both use many of the same tools used for development. E.g. go or terraform). Doing this is good for increasing the parity between development, testing and production environments.
• versioning each tool separately. In the spirit of breaking down large tasks and submitting small pull requests, we don't want to update the versions of all of our development tools at once. E.g.

let
	  go = (import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/<COMMIT-HASH-1>.tar.gz")).go;
	  terraform = (import (fetchTarball "https://github.com/NixOS/nixpkgs/archive/<COMMIT-HASH-2>.tar.gz")).terraform;
	 # many (e.g. 20 or more) other tools
in #...

Problem: downloading each of these many tarballs could add a lot of bloat to automation environments. E.g.: downloading https://github.com/NixOS/nixpkgs/tree/1c4d0f130b0536b68b33d3132314c9985375233c gave me 47.7 MB zipped, 181.7 MB unzipped. Multiplying these numbers by the number of tools you're using with nix gets unwieldy pretty quickly: it increases build times and amount of storage in caches (e.g. docker container registries). The overwhelming majority of files inside these tarballs are not being used. What are possible solutions that ameliorate this problem while making no compromises?

PS: maintainers can choose whether to interpret this issue as either just the question itself or as a request to document this in nix.dev .

Start with the pinned nixpkgs tutorial linked in the issue and compare its approach with the multi-version automation example in the issue body. Investigate possible ways to avoid repeated tarball bloat without compromising reproducibility; done would be a decided solution documented in nix.dev, if maintainers accept the documentation request.