[whpalmer4]

A couple of thoughts:

Just like you implicitly (or explicitly) do with parallel projects or action groups, picking one action to be the next action by putting it at the top of the list, you could just decide that one of those assemblies is going to be the first one you do. In fact, if you're doing this in a parallel project, not a Single Action List, the program is doing that for you if you use a Next Action view.

OmniFocus doesn't force you to do things in the proper order. Let's say you built the project as a sequential project, with just one parallel group for getting the materials (about as low effort as what you suggest):

Build the widget //
Get the materials { =
- Get Material M1
- Get Material M2
}
Build Assembly A1
Build Assembly A2

If you look at a Next Action view, it will suggest you build Assembly A1 first, of course. But if you just don't feel like building Assembly A1 today, or it is going to take more time than you have, you can look at the project in a remaining view in project mode, and see that there's something else that you could build, even though it will be styled as unavailable.

A different way might be to have the whole project be parallel, with a parallel action group to grab the materials up top. Again, if you look at a Next Action view, you'll only see the "get materials" actions until they've been completed. Maybe that's enough of a reminder for you right there? Or don't assign contexts to the assembly actions until you've finished the action group to get the materials.

As long as you're the one running the software, use it to make your life easier, not harder. Don't sweat whether your control structures are provably correct in all cases, just use them as a framework to remind you what you need to do. No one is grading you on the elegance of your archived actions, right? :-)

Here's another wild idea -- who says a project has to stay sequential or parallel for the entire duration of its existence? If you don't like making the groups, just change that as appropriate when you review the project. If you had a slightly more complex example, where you had to do a bunch of parallel actions (doing research on a subject), then a handful of sequential actions (downloading and installing a toolchain), followed by another group of parallel actions (flood the App store with dozens of similar applications), you could just write them out as an ordered list, and switch the project back and forth between being parallel or sequential as you went. Or in the simpler example diagrammed above, switch the project to parallel once you've completed that initial group. Wouldn't you do that if you were keeping track of the project with pencil and paper?

I'm not in any way trying to suggest that your suggestion is a bad one, and I'd probably use it if implemented. But I think you'll agree that it is a feature request that doesn't really add any substantive new functionality to the product, and I suspect it is going to be very difficult for such feature requests to bubble up to the top of the execution stack for the foreseeable future when Omni is pushing back long-promised major new features that have vocal community support.