Four points...

First, on this...

T6638: Be able to find tasks by "is a blocker to task Y" or "is blocked by task Y" in the search interface

I kind of don't think we should put this on the search UI. Instead, having a link or icon or button on the task seems better, e.g.:

Blocked by: T123
            T234
            T456
            (View these tasks as a search result set...)

The idea being that the only real use case is to take them to the bulk editor, I think.

We could possibly even just "(Edit all these tasks...)" and give you an option to get back to the search result view if you want.

That would be kind of heavy for a very rare need, but maybe we can come up with some reasonable treatment eventually.

Second, consider this API instead:

->withBlockingTasks(true | false | null)
->withBlockedTasks(true | false | null)

...where true means "find only records with this attribute", false means "find only records without this attribute", and null means "ignore this attribute".

This prevents impossible queries like DEPENDENCY_BLOCKING + DEPENDENCY_NOT_BLOCKING and makes the eventual Conduit API easier to use. The UI would be two select dropdowns instead of 4 checkboxes. I've been doing this with recent APIs in this vein and it seems to work well -- I think the only drawback is that true vs false vs null feels slightly magical.

Third, we have a handful of open tasks which are all "add some fairly easy to implement but not-especially-valuable filter for some rare-ish use case"; I consider this one of them. Others include:

• T5352: Add ability to filter tasks on blocking status in search queries (this task)
• T6717: Improving the usability of Maniphest's advanced search (desire to reorder the fields without strong rationale)
• T6721: Would like ability to search tasks by title
• T6821: Allow querying for open Maniphest tasks with an assignee set for ages ("cookie licking")
• T4434: Track object closed/completed date and actor

I'm hesitant on all of these because I think adding more rarely-used fields to the query interface becomes a net loss at some point.

T4100 will let us collapse some of these fields, but the desire to add limitless numbers of new fields seems irresistible in the long run.

I wonder if we should make the fields themselves editable and allow users to save configurations of fields -- so you hide the fields you don't use often, reorder the other ones, and save the result as your new search template. On the one hand this would let us add hundreds of query fields without degrading the product much; on the other hand this is a major amount of both UI complexity and technical complexity.

Finally, I caught some inlines.