[Fermey]

I think what it amounts to is that there *are* valid reasons why one task could validly be on more than one context list. The easiest example to provide is a situation where you have phone calls that you want to make in the office, phone calls that are personal (home) calls, then calls that might be validly be made either at work or at home.

I don’t think it would invalidate David Allen’s system by allowing tasks to be on more than one context list. In fact, I’d argue that Allen would say the advantage of automated tools like OmniFocus over paper lists is that you can easily have one task fit in more than one context. Because we are stuck with one context in OmniFocus, we are left with workarounds that never quite satisfy user’s needs.

Brian, I appreciate your taking on this issue head on in one thread, but what it sounds like to me is excuses for avoiding a many-to-many relationship in the OmniFocus database, which would likely hurt performance and make it a lot more difficult to develop. Let’s face it, messing with the OmniFocus database structure wouldn’t just affect one program, but three (OmniFocus for Mac, OmniFocus for iPad, OmniFocus for iPhone). I think most of us would be happy just to have the long-awaited version 2.0 arrive on our Macs. :-)

I believe it’s disingenuous to say that the OmniGroup doesn’t want to implement multiple context tasks because it adds unnecessary complexity and the added complexity prevents users from getting things done, as stated in one of your original posts. True, that added complexity would make it more difficult for the *OmniGroup developers*, but if there is one thing I’ve learned after reading all these workarounds is that these workarounds themselves add unnecessary complexity.