I implemented this, sort of. However, it doesn't work cleanly because transactions are "adjusted" (have old values populated) after they are "expanded" (which generates the @user mention transactions). So when the code runs, it doesn't have access to the old text and can't easily figure out which mentions are new.

I don't immediately see a way to fix this cleanly. I think reordering transaction phases is probably the right approach, but that would affect everything and probably have some unintended side effects.

It's possible to hack this together, but I'm going to sit on it for a bit and hope we can pursue a cleaner fix in the relatively near future, maybe after something triggers T9789 to happen. That change would require extensive testing of things anyway, so it would be more reasonable to bundle changes to phase operation along with it.

See also T11134

Current state of the world after D16108 is:

• editing comments uses the correct rule (only new mentions count).
• editing other fields still uses the old/wrong rule (all mentions still count).

Fixing the "other fields" case is complicated, per above, and I plan to wait and see how T9789 and adjacent work develop before planning how to continue forward here.

Can we please add the keyword subscribe or subscribers in this task title? I looked through 2 pages of subscribers search before filing a dup. I know now I was searching the wrong term, mention would have given it to me instead. But they are related.

T9789 has stabilized (the majority of major transaction types now run through ModularTransactions) although it didn't end up providing much clarity here. This is no longer blocked on anything, I just need to develop a specific technical plan to resolve the "adjust" vs "expand" sequence inside transaction application so the "expand" code has access to the old text by the time it runs.