Kanban-style boards are popular for visualising a project management-level overview of ongoing, future, and done work. https://phacility.com/phabricator/maniphest/ suggests these are a key feature of Maniphest. The classic example, using Post-It notes, essentially has one column for each task status:
Workboards in particular provides a good example of something which uses something which is superficially similar (columns on a board!), but does not involve mapping status to column, so is not affected by this issue.
I have been using Phabricator for sprint projects in an internal deployment at my company, using Kanban workboards°. When using columns to reflect task status, everyone has to remember to update both task status and workboard column. Not doing so means that the two can get confusingly out of sync.
Anecdotally as the cause, I see two behaviours which frustrate each other: project managers sweep, organise, and manipulate via the workboard view (reflecting column membership), and developers primarily work via 'queue of stuff' views such as the dashboard and Maniphest landing page (reflecting task status). Each wants a different view for different reasons: PMs want to assign and organise, and developers want to work through a semi-linear work list. Each group may not realise that they've forgotten to update the other view, since they may not look at it day-to-day.
Ultimately, having to perform two actions (update task status, change project column) for one semantic action (change task state) is not just error-prone, but also busywork; I would be in favour of anything which gave the least amount of friction. But mostly, I want to make sure that the two can never get out of sync.
T5474 would solve this problem from one end¹: moving a task between columns will change its status. However, there is still an opportunity to have the two out of sync with each other, by changing the task status and forgetting to update the column, as developers are wont to do. It also doesn't support a 1:n column:status model; you may have an extended set of statuses ('in QA', 'awaiting deployment', etc) which map to the same high-level state ('dealt with for now').
Coming at this from the other side, and providing query columns, or column-like views would remove this possibility: the user would only ever update the task status, and the status columns would then always be in sync. I imagine this as allowing me to add/configure a column with something resembling the current filter dropdown; in particular, having the advanced filter available would be both consistent and powerful.
Somewhat separately, these query views would also enable orthogonal column views: in addition to a Backlog/WIP/Blocked/Done/... set of columns, you could also add views for bugs/features/epics, or other task classifications².
°: Generally, we have a top-level covering project, which contain one milestone per sprint. The sprint milestones have columns roughly as in the picture (backlog/WIP/blocked/done), reflecting task statuses.
¹: I don't think the exact converse of T5474, using triggers to manage explicit column membership, would be a good solution here. @epriestley validly points out that this would complicate multiple tags/projects, where you may want to manage column membership separately per-tag. Also, it would require new UI to be able to associate workboard columns with the triggers, be it tagging the columns or using substring matching; this is because the list of task statuses is globally well-defined, knowable, and immutable; not so with the set of workboard columns.
²: I can expand on this if it's helpful, but didn't want to entangle it with the core problem.
