WTF coupling between $form_state['cache'] and form processing

At the same time, it might be puzzling, as people might find that their fields got 'eaten'?

I agree, Let's consider the keys in question:

• always_process
• must_validate
• rebuild
• redirect
• no_redirect
• temporary

Which of these would a developer expect to be able to set from a form builder callback or a hook_form_alter()? Of those, for which (if any) does it make sense for the behavior to be different depending on whether the form was retrieved from cache or not? For the latter question, I think only 'temporary' could fit that bill. 'always_process' is an odd one in that it is somewhat incompatible with form caching anyway (its purpose is for simple GET forms where you don't want to pass things like 'form_build_id' in the query string). But for the other four, I think we really need to ask the question of whether we intend to allow developers to set them during a form builder callback / hook_form_alter() or not. If yes, we need to remove them from form_state_keys_no_cache(). If no, we need to document that clearly, so people aren't puzzled by their $form_state settings getting 'eaten'.

For anyone becoming concerned that the Form API was in danger of becoming understandable, here's a patch that adds a little more ugliness relative to the original one. It adjusts for #3.

While this issue isn't critical, it touches on deep enough FAPI internals that I think it deserves the "D7 Form API challenge" tag, lest we forget about it.