Good move to fuse these discussions into one thread. I will not repeat much here, as I have explained most of what I think would be the best solution in those other threads, so I will just refer to them indirectly, if necessary.
What I will focus on here in this post is just comment on some of the “new” aspects that you just toughed upon here, namely what is “GTD methodology” and what is not, as this is often an area of confusion.
I think it is important to know that apps such as GTDNext are already quite a bit “beyond” core GTD as described by David Allen (DA). GTD is designed for paper, and is represented most closely by apps such as Wunderlist or iOS Reminders, i.e. flat lists without any linkages between lists and without any hierarchies.
I personally like the “advanced” style of GTDNext and similar apps, which goes way beyond core GTD, but it is necessary to be aware of the fact that there is often no GTD terminology for the things we are discussing. For example, words such as parallel and sequential, sub-projects, “true” Next action, dependent actions etc are simply not in the GTD vocabulary.
So, if, apparently, we all want to go beyond core GTD and still want to stay perfectly in line with GTD, I think it is best to look at what DA really does say:
GTD only deals with actions and projects
DA says that for most people most projects tend to be small. He does mention that some projects can be very big, with multiple levels, Gantt charts etc etc., but he leaves that aside. The methodology only covers actions and projects.
GTD assumes no documented linkage between action and project
The list of projects is just that - a flat list of projects. It serves as a list (or checklist) of “reminders” (a term frequently used by DA for both actions and projects) of what projects you have to deal with. During your review you simply look at each item on the list (each project name) and quickly dream up a few actions (Next actions or others) that are now relevant to list (list on your current GTD main lists Next, Waiting etc). DA says it is not even worthwhile to write down which project a given action relates to, as this is often obvious.
GTD’s “project support” is where the future actions are kept, if you even have any
The main GTD category lists (Next, Waiting, Someday/Maybe) are lists that should be useful and meaningful to look at and consider doing something about now, anytime. If you have a project in which you have foreseen or planned some actions which are not possible to get done yet or not relevant to list yet, the place to keep these is in the GTD bucket called “project support”, the organization of which is not described, but whose contents comprises anything and everything that is not on the main lists (things like budget, brochures, project plan etc)
GTD can have any number of next actions in a project
DA says it is essential to identify every next action in every “moving part of every project”, in others words identify everything that actually can be started now, which can be at least one or more actions.
GTD requires conscious activation/deactivation of projects
In GTD you should not take on more than you can handle, and “prioritization” takes place primarily at the project level, not the task level. It is necessary to review the list of projects and decide which ones are going to be active.
Conclusion - how GTD relates to GTDNext
The whole discussion about sequential vs parallel defaults and true next actions is totally beyond GTD. In GTD, only “true” next actions are next actions. Period. Everything else is “project support”. And there are no rules for how to automate the transfer from the inactive “projects support” bucket to the "active GTD lists. A manual/mental approach is tacitly assumed.
So what we are in fact talking about here is a way of “integrating” some of the contents of “project support” into the same app that also manages our current main GTD category lists. And also to automate the transition of such “project support” action into a regular (currently active) GTD action on the main lists. There is no GTD terminology for this.
I think probably the only major principle we can carry with us from core GTD is that we must not clutter our current main GTD category lists with stuff that is not yet relevant.
You have already chosen a path with flexible-depth hierarchies. This is very nice. Even though it goes way beyond core GTD it does not in any way break it. And it opens the door for very complex planning of the future. But what it also does is it half-shuts the door for “noobs”. Obviously it is easier for a “noob” to have Actions vs Projects clearly identified with separate names and icons etc, rather than have an infinite hierarchy of little square “nodes” which can represent virtually anything. But there are sufficiently many apps out there already for “noobs”, so I think you made the right choice, There are plenty of people who want to go beyond core GTD.
I think it seems unwise, though, both from an engineering point of view and from a user simplicity point of view, to have different defaults and adjustment mechanisms depending on what level of the hierarchy we are at. It is difficult enough as it is. It is easier to have one principle that applies generally to “a node with child nodes”, whatever that node and its children represent. Also, if you start to build in assumptions about what all the levels are going to be used for in real life (e.g. assume that level 2 from the bottom is necessarily a “sub-project for knowledge workers”), then I think you are creating many more problems than you are solving. (If you are going to have different rules for different levels, then you’d probably be wise to consider having different names and icons for them, too, to make it easier for people to understand each level’s unique set of features.)
Automation is obviously more valuable at lower levels, with a higher “churn”. It is not necessary to have it automatic, of course, but it is certainly neat and convenient, if implemented appropriately. Automation can also be of value at the next level up, e.g. if that level is a small sub-project with tiny tasks, and the 3rd level (above that) overall moves much more rapidly forward that you care to review it. But generally speaking, automation has lower and lower value the higher up you go, so if there are engineering reasons for limiting it to just one (or two or three) levels, then I do not think this will be a dealbreaker for anyone. There will be some difficulty for new users to “learn” that automation stops working above a certain level, but if that’s the only difference between levels, then I think you should be fine.
GTDNext on/off switching for "nodes"
The crucial thing - simply a must at all levels - is to able to individually switch selected nodes on or off (activate/deactivate projects etc). This is even part of core GTD. Currently it is not so. All items are “on” and there is no way to switch them “off”. http://forum.gtdnext.com/t/loophole-in-sequential-task-progression
It sounds now as if you are thinking about introducing the rigid one-or-all option from the 2nd level and up, and this I’d say is definitely a no-go. It adds no value, solves nothing, and if anything just makes it more confusing (to have a separate principle). There must be an individual switch for each item. Simple. And there is no way around that, whatever defaults you apply.
As I have said before, it matters little from a pure GTD point of view what defaults you have as long as the default decisions can be changed on an individual basis for each item. That is the key point. As I have said before I think there is strong case generally speaking for applying parallel (could be called Normal) as the general default. http://forum.gtdnext.com/t/recommendation-parallel
Regardless of what the general default is, I consider it essential from a safety point of view that items that are not entered carefully using the Workflowy mode but are instead “tossed” into a project (node) using menus or dropdown lists etc without being deliberately placed are set to be “on” by default (active, parallel, whatever you care to call them.) Having such items set to “off” (sequential) by default would necessitate many unnecessary visits to the project just to correct this, and will inevitably lead to important actions being overlooked whenever the user forgets to correct the default setting.