Comments
Resources are things, and things can have states. If there are rules in FHIR for when an stateful thing should be a resource, versus when that stateful thing should be a resource with a status value, they are not clear. In FHIR, an order for a thing is often a resource (NutritionOrder, DiagnosticOrder), and a request for thing is sometimes a resource (CommunicationRequest, ProcedureRequest). However, many resources have status values like "requested" and "proposed" and "planned" which could easily be "promoted" to resources (e.g. CommunicationProposal, ProcedurePlan, ProcedureProposal) to be more like DiagnosticOrder. On the other hand, resources like ProcedureRequest could easily be "demoted" to status values (e.g. Procedure with status=requested). There does not seem to be a consistent dividing line between when something is a resource, and when it is a status. It would be desirable to have consistent rules so there is no ambiguity between a lifecycle stage and a resource.

Grahame's Comments
well, ok, but you assume that clinical practice and understanding is consistent, which is often not the case. In FHIR, we prefer consistency with the domain over internal consistency, but that doesn't mean that we can create inconsistency for no reason. I think it's one thing to have a status for various aspects of future, vs a status code that crosses into the past. This frequently modulates all the definitions of every field, and often they are incompatible. Are there any cases where status cross the future/past boundary? if there is, I haen't noticed them. So I don't see design inconsistency here, but there is inconsistency around planning; this is already an open issue that is the subject of further work