Q:

Why state cannot be part of Presenter in MVP?

I read http://www.codeproject.com/KB/architecture/MVC_MVP_MVVM_design.aspx and it said:

As powerful as they are, both MVC and
  MVP have their problems. One of them
  is persistence of the View’s state.
  For instance, if the Model, being a
  domain object, does not know anything
  about the UI, and the View does not
  implement any business logic, then
  where would we store the state of the
  View’s elements such as selected
  items? Fowler comes up with a solution
  in the form of a Presentation Model
  pattern.

I wonder why Presenter can't hold View state? It already holds all View logic.
As far as I understand, in MVC and MVP the state is kept in View. In PM and MVVM the state is kept in the Presentation Model. Why can't Presenter follow PM in this particular case and contain the state of the view?
Here is another article which says Presenter does not hold View state, instead the view does: http://www.codeproject.com/KB/aspnet/ArchitectureComparison.aspx

A:

I think you are absolutely right when you say the view stores the view state in MVP: it's simply the way "concerns are separated" in MVP. In "clean MVP" view state is kept in the view and not in the presenter. The presenter can query the view for it's state using the methods provided by the view's interface.
Keeping state in the presenter will make your presenter a hybrid between presentation model and presenter. Be pragmatic and don't rebuild your complete app if you find yourself keeping some view state in the presenter sometimes. 
Just be aware of the general motivations to use either the PM or MVP patterns.
On Fowler's eeaDev web article on Presentation Model he states:

Presentation Model is a pattern that
  pulls presentation behavior from a
  view. As such it's an alternative to
  to Supervising Controller and Passive
  View. It's useful for allowing you to
  test without the UI, support for some
  form of multiple view and a separation
  of concerns which may make it easier
  to develop the user interface.

Fowler continues:

Compared to Passive View and
  Supervising Controller, Presentation
  Model allows you to write logic that
  is completely independent of the views
  used for display. You also do not need to rely on the view to store state.
  The downside is that you need a
  synchronization mechanism between the
  presentation model and the view.

I disagree with the statement you quote in your question:

One of [the problems of MVP] is persistence of the View’s state.

It isn't a problem: it's a choice. IMO Fowler does not mention this "persistence of view state" as a motivation to use Presentation Model instead of MVP, be it Supervising Controller or Passive View.
I'm not quite sure if Fowler with "to store state" means persistence in the sense of "across application life time". But regardless, the point is it's a choice with a trade off: when you use Presentation Model instead of MVP, you get 

better testability of view state
independence of view with regard to (storing) view state
"programmer" can create PM and "UI designer" can then separately work on view

at the expense of

having to sync the view with the presentation model

Note that the latter "expense" maybe less nowadays than at the time of Fowler's writing (2006), because of modern UI synchronization techniques, such as .NET's data binding.

