I think this is probably not something we're going to fix.

From a technical standpoint, we'd need to go recompute a bunch of revision states on every project membership change, which is pretty messy. Some installs have millions of revisions at this point. Although we can trim down that list, there's no way we could do this update in-process in a reasonable amount of time in all realistic cases. So this is just a whole huge chain of mess that requires new daemon infrastructure or running membership changes through the bulk tool. (We have to trigger the state change immediately because Herald, Feed, Harbormaster, external systems, etc., may rely on it -- we can't just wait until someone looks at the revision to resolve the state.)

From a product standpoint, I think the interaction would not be obvious, so we'd need to publish some kind of explanatory transaction on top of it ("jane added alice to Project X, affecting the state of this revision because both alice and the project are reviewers." + "This revision is now accepted."). This is a lot of complexity.

I don't think it's necessarily desirable. A user accepting a revision as themselves and a user accepting a revision as themselves and as a representative of a project like "Security" might really be different actions in the user's mind. For example, the user might be, say, a new hire to Security who hasn't been formally deputized yet, and be expecting someone more senior to clear the "Security" block. They might be surprised if their "Accept" suddenly starts to "count" a week later when they graduate into full Security membership.

Beyond that, there are very nuanced cases that I'm fairly certain we can't resolve unambiguously. Suppose this chain of events occurs:

1. Alice is a member of Security.
2. Betty is not a member of Security.
3. Alice accepts the revision.
4. Betty requests changes to the revision.
5. Alice resigns as a reviewer.
6. Betty resigns as a reviewer.
7. Betty is added to the Security project.

What is the state of the "Security" review now? Does Betty's reject beat Alice's accept now that she's a project member? I don't think there's any behavior we can choose here which is reasonable and consistent with the idea that membership changes cascade into reviewer state changes.

Finally, it sounds like this interaction wasn't really unclear, just unexpected.

Basically, revision acceptance is stateful, and that state only changes when you interact with the revision directly. I think this model is reasonable and fairly clear, and the least confusing / most consistent model we can select.