There is no formal concept of "updating a package" on a resource. It's considered deploying a new package version out to the resource.

While the model doesn't explicitly have a package update, we can potentially interpret a series of actions as an update and flag it as such in the audit trail. In many cases, when a package report is merged, for a particular package we will see one package version removed and another added (put in terms of the current InstalledPackageHistoryStatus flags, one will be "missing" and another will be "discovered"). The important thing to keep in mind here is that these are both package versions for the same package. We could potentially merge these two audit trail entries into one that is supposed to represent an "update".

This process would still allow a resource to have multiple package versions deployed at the same time. In such a case, there won't be a missing entry for the old package version and wouldn't trigger our update logic.

This is just one possible approach. Before pursuing an implementation, some more thought should go into whether or not this is even desired functionality in the first place.