I think your mental model is just not quite right, because an uploader +2ing the change they uploaded is absolutely "self-review".

If you are uploading a change, then you are asserting it is correct and appropriate and understood. For a cherry-pick, you may not review it too carefully because you know it was already reviewed, and that's fine. But as the uploader you are still asserting that you cherry-picked it correctly, didn't modify the code after the cherry-pick, resolved conflicts properly, and so on. After you upload any change, with that implicit assertion it is good to go, someone else has to verify (review) it and add their own assertion that it is OK (the +2).

The trust bits are separate from the review bits. They just count the number of trusted computers involved. They're not a substitute for the actual review counted by the +2 bits.

If you are uploading a change, then you are asserting it is correct and appropriate and understood. For a cherry-pick, you may not review it too carefully because you know it was already reviewed, and that's fine. But as the uploader you are still asserting that you cherry-picked it correctly, didn't modify the code after the cherry-pick, resolved conflicts properly, and so on. After you upload any change, with that implicit assertion it is good to go, someone else has to verify (review) it and add their own assertion that it is OK (the +2).

Ah yup, that is reasonable, especially given the uploader can alter the change during/after the cherry-pick (surprising I forgot this given how many times I did that recently). Given this though it still seems like we should be preventing the original author from +2ing? Or in that case are we asserting that the author is essentially verifying that the uploader properly cherry-picked their original change?

Or in that case are we asserting that the author is essentially verifying that the uploader properly cherry-picked their original change?

I think that is indeed what we're doing.

At least when I review cherry-pick CLs, I review that they are a faithful recreation of the original CL (and that the original CL was already reviewed and submitted), that the merge conflict resolution if any was good. The original change author makes for a good cherry-pick reviewer since they're already familiar with the original CL.

Note that at least in main repo's release branches, CL review is about making sure the cherry-pick went well, but CL submission is done by release managers who need to also confirm that the CL went through the backport process and was approved (i.e., has the CherryPickApproved label).