Currently in Omnifocus, a task with assigned on-hold context is, by definition, considered unavailable. That results in filtering redundancy: if you want to set context filter to ‘on-hold’, you also need to set availability filter ‘remaining’ in order to populate a perspective. What is worse, however, it is simply a waste in terms of potential filtering capabilities.
A real-world example using the most common on-hold type context: “Waiting”. In my “Waiting” perspective, I would like to be able to defer some of the tasks I’m waiting for. Although it is technically possible, there is no real gain as the deferred tasks do not disappear from the list. Why? Because deferred means unavailable and the task is already in this state because it’s been assigned the “Waiting” context.
Similarly, if one creates dependent tasks with pre-assigned “Waiting” contexts, all such tasks will clutter the list even though their predecessors have still not been completed.
Both cases could be avoided if availability was not taking context type into account. Then, it would be perfectly possible to create a perspective with the availability filter set to “available” and the context filter set to “on-hold” that would work as expected.
On the other hand, if one wanted to retain the current behaviour, he or she could simply filter by “remaining” tasks, exactly the same as required today. So nobody loses in such case.
Improving this functionality sounds like a 10-minute fix to me. I bet there is a dedicated function to determine if a task is available or not, hence all it would take is removing the context type from the equation. No back-end changes should be required to make it work. Unless I’m missing something here, I really wish it is not an awkward design choice but a simple omission that can be easily fixed in next releases.
