When upgrading a package, it is by no means unheard of for many of its
files to preserve their contents (though not necessarily their
metadata).  This phenomenon is particularly common for minor upgrades,
as with stable updates or many upgrades within development suites
(testing, unstable, and experimental).  In this era of reproducible
builds, it commonly even extends to compiled binaries such as shared
libraries, whose upgrades currently always trip needrestart.

It would be great if dpkg could handle this scenario with less formal
disruption.  At minimum, instead of unconditionally renaming .dpkg-new
files into place, perhaps it could compare them with the files they
are to replace (after confirming that they are in fact regular files)
and in the case of an exact match simply resync metadata and remove
corresponding .dpkg-new files.

A more elaborate approach could reduce peak disk usage in many cases:
immediately after creating a .dpkg-new file, compare it with the file
it is to replace, and in the case of an exact match discard the
.dpkg-new file in favor of an empty file with an extension of (say)
.dpkg-newmeta and the desired permissions and ownership.  The rename
phase would then check for such .dpkg-newmeta files and proceed
accordingly.

Thanks in advance for considering this suggestion!