"Revert to Base System" Changes Captured in Update Set, Do These "Count" as "Reverted" When Promoted to Production?

My understanding is that if I address a "Skipped Change" by selecting "Revert to Base System," the record in question will no longer be considered "Customized" and will not be skipped in a future update.

Question 1: Is this correct?

Question 2: I have noticed that when I "revert" a change, this is captured in an Update Set. If I promote this Update Set to my production instance, will it be considered "Reverted" in the same way as if I reverted it "in place" in Production?

Question 3: How does the upgrade process determine if something needs to be "Skipped" or not? I found a community post that explains "An upgrade will skip every record that was ever customized/changed. If you change any field it will be flagged "Customer updated" and will be skipped. The merging does not happen in a smart way, it just checks whether the record was flagged. So imagine that you have changed a string field from "foo" to "bar" and back to "foo". The value would be the same as OOTB, but the record has been updated, so will be skipped. Therefore, you should revert instead of just changing the value back." However, I can't find anything that looks like an indicator of "Customer updated," including when I exported the record as XML. The only "interesting" thing I could see on the record was that the "sys_updated_by" field was changed to "maint."

Essentially, I'm trying to figure out if it's a good idea to push these "reversion" changes to production in update sets, or if it would be better to perform the reversions again in production directly. (I suppose I could do this semi-efficiently by filtering based on file names if necessary.) I've inherited a large number of "false positive" records that were changed and then changed back without being "reverted," and they complicate my upgrades, so I would like to put them to rest once and for all.