[knome]

To save compilation time and bandwidth the authors might be able to make their package dependencies sort of inside out, using a smaller program simply to perform the needed library loading and dependency injection on the core of the software.

Then if you're going between versions, you can avoid having to update the lion's share of code just because the dependencies change.

    jabberwork-1.2
      jabberwock.core-1.6
      jabberwock.apache.interface-0.3
    
    jabberwock-1.3
      jabberwock.core-1.6
      jabberwock.apache-interface-0.4

Instead of having to update all the hefty ".core" modules, you could get away with only updating the hopefully lighter launchers / library loaders and the specific interface code being updated.

[taylanub]

I also started thinking things along the lines of that when I first looked into how Guix does things, but after annoying the developers a little (many thanks to Ludovic's patience) I've come to understand that things like that beat the whole purpose of having pure packages not only in binary content but also in run-time behavior.

Basically, reproducible builds are a red herring here. A package's identity is not only the hash of its byte-by-byte contents, it also includes ("closes over") the identities of all packages it "references" (depends on), meaning it will always have the exact same run-time behavior everywhere because even all its dependencies count as part of its identity.