[macula]

Thanks for alerting me to that change—I missed a few posts on this thread. I understand that now tasks "simply" inherit the context of their parent. In that sense, the context of a group action or project behaves as a "default" context for the children. Unless I'm missing something, then, the change you are referring to is rather nominal.

I have written my objections to this new behavior above but will gladly repeat here: Conceptually speaking, (my) action groups and projects do not really belong in any "real" context because they contain children of various contexts. At the same time, leaving the "context" field of groups/projects blank would not work either, because I would not want my "no context" view to mix groups/projects with single actions that I have left without a context only inadvertently.

Therefore, the best solution I could come up with was to create a "group/action" context, which would display those types of entities together in context view.

Once this step is taken, however, all children tasks automatically inherit this "group/action" context. And quite often I forget to notice this erroneous context, with the result that single actions are mixed in context view with groups and projects. This behavior is erratic because the expected outcome of neglecting to set a task's context would be to find the task in the "no context" bin rather than the "group/project" bin. At present, however, the user needs to check for "neglected" (e.g. hastily entered) tasks at two places: The "no context" bin (for tasks entered via the Quick Add pane) and the "project/group" bin (for tasks entered in the app's main window). It's inconsistent and clumsy, and truly jars against the overall elegance of this software.