With all due respect for the hard work you all put into these things, I think this change is a total disaster, and undermines the many benefits of having the clean divide between planning and acting.
It doesn't make sense
Projects contain actions that often (almost always, for me) have different contexts. So assigning a single context to a project is nonsensical. Plus you end up with truly bizarre results like projects grouped with themselves in a given context.
It's confusing to the point of uselessness
Okay, the next action is the thing I have to do to make progress on a project. But when I see a project in the context view, how can I know what the next action IS?
Or, wait, what if there isn't a next action? Do I need to assign one? Is it in this context? Is this a one-off project and can just be checked off, or are there additional next-actions I'm just not remembering?
The fact is, I can't SEE any of this, and these are not questions I should have to research when I'm just trying to buy groceries!
It crosses work modes
Projects and Contexts are two different organizational axes for my to-do lists. Each is used for different work modes; Projects for planning, Contexts for working. Essentially, each one represents a "context" of sorts -- with the Project meta-context being appropriate for my weekly review, and the Context meta-context being the one for the work day. Mixing these up causes me to break out of the flow of acting in context, and forces to to, instead, go back to planning mode.
It clutters Contexts and makes them far less useful
Under this new layout, I end up with a completely useless "No Context" view -- since it's overwhelmed by every project I have, and is no longer useful to triage actions without contexts. I'm confident that if I added more contexts to projects, it would do the same thing for other contexts.
I end up spending more time shuffling papers
Now, just to keep my program looking nice, I'm having to assign contexts (often arbitrary ones) to my projects, just to get them out of the useless No Context view. I want to spend LESS time categorizing things, not more. The whole point of contexts in projects was to set a default, not to categorize the project itself.
It breaks GTD
This is the weakest reason, because there's no reason to be married to canonical GTD, but it stands. Per The David, there is a difference between a project and a next action. A project is something that requires more than one action to complete. An action is an atomic task, that can be accomplished in a given context. Projects do not have contexts.
It blurs the distinction between contexts, projects, and actions. Per "canonical" GTD, contexts and projects are individual lists. They're organizational axes. The point of the two views is to give two different perspectives on the same task: A Planning and a Doing view. These represent not just different views of my action lists, but different modes of work. My review/plan action is in the project view "context," and my work day is spent in the context "context."
The cure is far worse than the disease
Honestly, I don't see what this is fixing. Yes, it provides a means to make those one-off actions peers to projects, but I'm not clear that's necessary. OF already supports bucket-projects, and they work great. Actions show up accordingly, and you can prioritize those buckets according to your own priorities or available time. Easy peasy.
If you're worried about things falling through the cracks, the stalled projects perspective and other custom perspectives give great visibility to these things. Then "No Context" can also be used to find actions that need to be triaged (Although not with 1.8's changes -- then "No Context" becomes a trash heap of contextless projects)
And the downsides to this are immense, as I've enumerated. It's contrary in so many ways to the basic workflow that OF supports.
If there is a need to categorize projects by context, why not just have a Context group in the project view that provides this? Then you have projects-by-context, and it's not conflated with actions-by-context, which are often contrary to the parent project's context, anyhow.