so the relation with the project can still be identified after moving the task to a different space

This seems very brittle overall. What's the root problem you're facing that makes this a suggested solution?

In T10408#160933, @chad wrote:

so the relation with the project can still be identified after moving the task to a different space

This seems very brittle overall. What's the root problem you're facing that makes this a suggested solution?

Setup: I have several tasks in spaces. These spaces are often directly linked to projects (i.e. they have Visible-To:#Project set). The tasks are each logically related to the space's project.

Now one might think that the space would be enough to query all tasks related to a certain project, buuuut...

Problem: If I move the task from one space to another, there is no way to know which project it was originally associated with.

Attempt at a solution: Use Herald to assign the appropriate project to all tasks in a space. Now, the relation to the project would be a bit more "permanent" than with spaces that might have to be changed more often.

Does not work, because: Described in the original report. Blindly assigning a project with Herald removes the relation to any subproject that I might have manually entered.

Suggestion for a proper solution:

• Variant 1: Extend the "projects does-not-include #X" check to mean "projects does-not-include #X-or-any-subprojects-thereof". (If you plan to introduce exact(#X) as described in T10349: Projects v3 Errata - this behaviour would then be consistent with the new selector and rP14ae3c099c2e: Make queries for Project "X" mean "X, or any subproject of X".)
• Variant 2: Add another "projects does-not-include-subprojects-of #X" check. (If you don't introduce exact(#X) as described in T10349 - which, to be consistent with other queries, would also mean reverting rP14ae3c099c2e4ce6c706bbaa4aa9fcb4bc7d3dec, IMO.)