Introduction
This discussion is based on the ControllerTaxonomy. Please read that first.
At a first glance it may be difficult to see the distinction between some PageFlowCentric approaches and those with SeparatedConcerns, particularly the ActionResponseModels. Many of these allow a programmer to specify which "view" should be shown depending on, say, the result (or outcome) of some action. The difference, though sometimes subtle, is important (as indicated by their respective positions in the taxonomy).
To a SeparatedConcerns strategy (particularly the action-response models), the notion of "view" is basically the template to be used to generate the resulting document for the current request. At base, these approaches are attempts to generate a response for a request, using a template---they just allow the programmer to specify code separately from the template, and provide a means for that code to influence which template will be used (there is also not a strict one-to-one mapping between the template used and the request URL). These approaches are the most sophisticated, youngest descendents in the lineage of: StaticFiles, ExecutableTemplates, SeparatedConcerns.
A PageFlowCentric strategy defines its notion of "view" more strongly as being a logical location in the UI and it keeps track of where the user currently is: when a request comes in, the server will have some way of determining where the user is (in terms of its conception of logical location in the UI). Its specification of page flow specifies not which template should be shown in response to a request---it has a wider, higher-level scope: it states which logical location can be transitioned to from others, depending on certain conditions. Such a transition thus changes the server's notion of the current location of the user in the UI.
While strategies with SeparatedConcerns are essentially presented as techniques for specifying web sites containing several dynamic pages, PageFlowCentric approaches are presented from the important perspective of aiming to specify UIs as single entities (which happen to be delivered via the web).
It is also interesting to note that the strategies presented here as distinct are often combined in a web framework. For example, an implementation of a PhasedRequest can be built by having PublishedObjects, each of which is mandated to have methods named for particular phases in the request cycle. The appropriate method of the object denoted by the request URL will then be called during the appropriate phase of the request. When categorising such a combination of strategies, the differentiation is based on the basic intention of the whole combination, not how that intention is achieved.
(Continue the discussion here...)