Let's add the terms to my summary: we generally start with a problem, something we're not happy about; then we design a plan to solve it; executing the plan is a task.

A plan can only have so much detail. Doing sub-tasks I didn't plan in sufficient detail, or which turned out to be unexpectedly difficult, are the remaining sub-problems. We should seek the best balance between pre-planning and deferring until a problem is encountered, and this is not trivial. Is that what you're talking about?

Otherwise, your list headed The approximate ways in which a "have to" might be a problem can be simply restated as "the cases where there is no obvious plan": when I lack procedural or propositional knowledge, or resources, which (I believe) are necessary to solve the problem. And then I can come up with a plan for when I've acquired them and go solve the sub-problem of getting what I need.