The email body says Herald added a comment.
The email subject line header says [Changed Project Column] (not [Commented On]).
So I wouldn't say it is incorrectly attributed.
AFAIK there are no Herald rules which trigger a separate email notification on its own (but I agree that the described behavior also has confused me in the past) as Herald rules are always triggered by some other previous action.

Uh! Out of curiosity, what does the notification look like in your web notifications?

Ahh but Transcripts do render an exception when it fails at least. I get a HeraldInvalidConditionException printing Invalid Condition: Condition references a rule which does not exist!, triggered in HeraldAdapter::doesConditionMatch() (only if you reach that condition in the evaluation of course, because https://we.phorge.it/source/phorge/browse/master/src/applications/herald/engine/HeraldEngine.php$437-445 ).
That's called in HeraldEngine in the line $is_match = $adapter->doesConditionMatch (note that class also has a method with the very same name).

Uhmm, transcripts at http://phorge.localhost/herald/transcript/33065/ never ever render a Herald rule condition (disabled or not) within another rule, it seems

On a more meta level, Maniphest isn't well-suited to be an entry-form to be filled by a non-expert user; Nuance is/was intended for this use-case.

on the technical level, Herald can't block object creation - it runs after the fact, by the Daemons.

I don't believe in playing whack-a-mole on "could this be a password" but a use case I've been recently thinking of is "Do not allow task creation when task content/data is exactly the defaults provided by the Form used to create the task". Basically: You were supposed to fill in some stuff but you did not when creating your task.

@valerio.bozzolan Thanks a lot for your help, debugging, deeper investigation! Resolving.

Just trying to convince you.
If the feature works, it adds functionality that can't be easily replicated. You can have a bunch of complex Herald rules and bypass them all just by declaring that ^temp/ refs are now non-permanent. If the feature doesn't work (or maybe doesn't exist, rather), you have to go to each Herald rule and explicitly exclude ^temp/ branches, which is a lot of work for something that (at least for me) looks like it should be simple.

I'm not, personally, 100% convinced that the hooks should be blocked from running on these refs - there's plenty of edge-cases where this might be even more confusing (commits can become published in a bunch of ways).

I could reproduce this locally:

1. As an admin, go to http://phorge.localhost/herald/create/
2. Select "Maniphest Tasks"
3. On http://phorge.localhost/herald/create/?adapter=HeraldManiphestTaskAdapter , select "Global Rule"
4. Under "Conditions", select any of and set the three conditions Description | contains | Internet Archive, Description | contains | archive.org, Description | contains | Wayback Machine.
5. Under "Action", select Add projects | someProject
6. Select "Save Rule"
7. Trigger the rule by creating a new task.
8. Wait, wait, and wait, then look at the Herald Transcript linked from the task.

It's unclear to me whenever Wikimedia needs this. If yes, feel free to also mark as Affects-Wikimedia. This is probably their use case: https://phabricator.wikimedia.org/T332639