Votes should not be unlocked if the Community user makes an automated script edit

Question

(Not a duplicate of Preventing bad edits from unlocking votes, as that covers users editing posts to unlock their own vote; this is about automated scripts editing posts.)

This may seem like a minor bug, and I thought so too for a long time, but I'm reporting this now because the supposed scenario I thought of at the time actually came to fruition recently. (This isn't a duplicate of that either, since that's a question asking about the scenario and why it happens; the answer points to the fact that automated script edits were made. This is a follow-up request from that answer.)

Votes are locked after a 5-minute grace period. Any edit made after that period unlocks the vote permanently. This is no matter what edit was performed (major and substantive, or really minor), and no matter whether the edit was done by a human or by an automated script written by SE.

In the above case, a user had many of their posts unupvoted as a result of the script that edited HTTP links to HTTPS a while back. Not too far while back, we had a user suspended as a result of massively unaccepting answers; such massive vote retraction would be prevented by this.

Note that we already have a special case for such edits: they are explicitly prevented from bumping posts, while other forms of Community user editing (e.g. anonymous edits) do bump posts. Can we piggyback on this to make it so that the Community user's automated script edits don't unlock votes?

Answer 1

I don't really like vote-locking (especially on metas), but given that we have it, it should behave consistently for all edits. Community♦ edits just aren't that special. If somebody has exploited it to conduct "targeted unvoting", deal with that user.

I'm pretty sure that the way vote changes work for the vast majority of us is: we vote at some point and move on. Sometime later the question crosses our screen again and we think "no wait, my vote on that was incorrect" and try to cancel it. If there's been an edit that works; if there hasn't it doesn't. It doesn't matter what the edit was; most people in this situation don't look at it and are evaluating the post anew. (I'm not talking about cases where you were involved in a discussion after which you want to change your vote.)

Feature requests need to make a convincing argument to invest in making a change, especially if that change would make the code more complex and the interface more confusing. ("Wait, that edit was after my vote -- why can't I reverse it?", said confused users on metas across the network.) This question argues on the basis of a single incident and speculation that enough people to matter will deliberately exploit it to punish specific users. I find that reasoning insufficiently convincing.

A final note: scripts aren't the only thing that cause edits attributed to Community♦, so you can't just look at who edited when the state needs to be calculated.