In general when you alter a table containing address or custom data relating to a contact a trigger updates civicrm_contact.modified_date.

We disabled this for the wmf_donor table on the basis it is 'is a cache anyway' but I think the best way to proceed with the silverpop incrementalisation is to put it in place.

Looking at the commit history I feel like we disabled the trigger more because it seemed unnecessary and *might* cause performance issues than because it was known to be causinng them. The same commit disabled triggers on the much more aggressively updated civicrm_mailing_provider_data table.

If we don't re-enable triggers on this table (or on civicrm_contribution) then we can mostly reconstruct the data from the modified_date in civicrm_contribution. Technically there would be a gap because a contribution moved from one contact to another would not identify the old contact. Normally this would only happen in a merge and the old contact would be deleted anyway and I can't think of a really solid instance where this would be unreliable but it also creates complexity on the silverpop side where we don't have a single point of reference for when a contact was last changed, and this value is what we want to drive our decisions as to which contacts to update.