Its a great question. It reminds me of a human stem cell that can become one of about 250 specialized cells in the body. There are design patterns for this in OOP languages but DBAs tend to stick to Codd's rules of normalization.

I've often felt there was a trade off of creating specific tables for each state if the data requirements were radically different for each processing state. That would also simplify the state change rules in your procedures by spreading them out over many state specific procs. In most of my projects there is only a stored procedure "interface" so the actual tables are always hidden inside the "object" and implementation won't matter for the programmers.

On the other hand, if you use different tables for each state, many SELECT procs may need to be updated to handle each new state table that is added. You'll end up with lots of joins and unions.

I prefer NOT NULL foreign key columns so as to eliminate OUTER JOINS so I lean towards the one table per state implementation but only if your rules are so complex as to warrant treating the 'object' as a separate table/entity.

You may create composite views on subsets of states to handle the retrieval problems. You may also break off the varying sets of columns per state and create child tables to handle them (just to avoid numerous columns being null and technically not available per some states).