Yes, there is. When you're doing multi-version upgrades, the "canonical" version is really "the canonical version for the most recent version of the package which may be different from the version that the original upgrade script was tested against." The only way to protect against version skew is to copy in the package definition as it existed at the time the upgrade script was written.
Now, this can be difficult to maintain if the package definition itself is in flux at the time the upgrade scripts are being written. I suspect we could find a way to manage this through coding conventions and or directory layout conventions (e.g. save a copy of every canonical version in systematically named directories) if there was interest.
