The checksum described in this proposal applies to each separate FITS Header and Data Unit, that is, to each separate FITS extension in any given larger multi-extension FITS data file. It would be equally possible to define a single checksum that applies to the entire FITS file, including all extensions, but since in either case the 1's complement checksum is zeroed for the entire file, there is no advantage to the latter interpretation.
A single, whole file checksum also implicitly assumes that the individual FITS extensions are related to one another in some intimate fashion. This is not necessarily the case - the separate extensions may simply be concatenated into larger FITS files for I/O or indexing efficiency (as with the NOAO Save the Bits archive, see ref. 8).
Even if the individual extensions in a given FITS file are related to a single observation, or form some other coherent data structure, a particular user may need only some of the extensions. Stripping unneeded extensions from the FITS file is trivial if a per HDU checksum is defined, since an individual extension with a zeroed checksum may be removed without affecting the (zeroed) checksum of the entire file.
A per HDU checksum offers maximum processing flexibility as well as flexibility of interpretation. Even if a programmer decides to update a checksum by re-accumulating the checksum over all the FITS records (rather than by using the end-to-end, incremental calculation described in §3.3) this will be far more efficient on a per HDU basis.