It plays well with the Debian reproducible builds stuff to weed out as much non-essential variation as possible.

For certain packages, I'm guessing the byte-savings could be near-infinite. Already programs are encouraged to ship `foo` (potentially arch dependent) and `foo-data`, but imagine updating "just one font" in a blob of fonts, and not having to re-download _all_ other fonts in the package.

For some interpreted-language packages, these deltas would be nearly as efficient as `git` diffs. `M-somefile.js`, A-new file.js` and just modify the build timestamps on the rest...

The answer to your question should be relatively straightforward: just run it on a base/default major version upgrade and see how many MB of files have the same `md5` between releases?

I've used this, I think it depends on what speed the connection to your Debian mirror is. It and the apt meta-data diffs definitely helped when I had slower Internet.

IIRC Google does something similar for Chrome browser updates.

Well, like everything else: Is bandwidth your primary problem, or is CPU? Whenever I run apt now, download time is nearly nil but installation time is forever. Increasing installation time (and complexity, and disk space and cacheability on the mirrors) for saving some download time is unlikely to be a good tradeoff. Of course, if you are stuck with severely metered 2G somewhere in the woods, you may very well think differently. :-)

Similarly, I've turned off pdiffs everywhere; it just isn't worth it.