We don't currently plan to implement this. Instead, we're going to implement triggers. Triggers would let you change task states or projects as they moved between columns, and then you could query by that derived field.

Some context from elsewhere:

Broadly, I'm hesitant to start making column names meaningful, since I think it's very surprising that naming a column something specific could imply behaviors, and we can't show the user available names or what they mean if they're all ad-hoc (you'd have to write a big wiki document with all your conventions or something like that). Especially for large companies, I worry that letting Phabricator have rules like "Columns named 'In Progress' do <something magical>" will get confusing, and we're always going to have some cases where users misspell a column name as "In Progess") or whatever and it isn't obvious why nothing is working like they expect it to.

We might end up changing direction here since it's a relatively common request to make column names queryable or otherwise meaningful, but I'd like to explore alternatives first. To me, it feels like we're always going to have weird rough edges if we base this stuff on the actual column names.

We're currently using columns as lightweight "subprojects" - i.e. our Bugs project has a FIXME column for higher-priority bugs. Would the recommendation here be to just use a subproject?

I think when one searches for something, or filters by something, that something does not need to have a "special meaning". Searching for "sandwich" does not require Phabricator to know or care what a "sandwich" is.

So I think that filtering by "columns named" does not force Phabricator to have special knowledge of which columns can or do exist, or a responsibility to explain to the user what the meaning of said columns is. Obviously the user has some notion of it or they wouldn't be trying to search by it.

In our use case it would be great to be able to pull up all diffs which are in a (correctly spelled) "Final Code Review" column.

If triggers (described in T5474) would not solve your problem, feel free to file a new feature request describing your problem (see Contributing Feature Requests, Describing Root Problems) and we can discuss approaches.

Offhand, I suspect that a trigger which automatically adds and removes a project tag like "Ready for Final Code Review" would probably give you a way to accomplish the same goal.

If triggers would solve your problem and you'd just prefer we prioritize this feature over other features, see Planning.

Yes, triggers sound like they'll do the job. Not to say search and filterability still wouldn't be handy in more ad-hoc cases. Triggers require foresight.

But in this particular case, a trigger to add a tag will work.