In MVP I see the presenters as the orchestrators of activity. As such they are the natural choice on which to base the composition of an application.
Exposing the view of a presenter to other presenters breaks the idea of encapsulation within the MVP pattern. While it doesn't reduce the reusability of the component exposing its view, it does reduce the reusability of a component making use of another component's view as it increases that components dependencies.
So I would keep the views private to the presenters and only let the presenters communicate with each other.
Elaboration in response to comment
When I say keep the view private to the presenter, I mean private: not exposed to the outside world except through the mediation of the presenter. Of course the presenter can expose methods to the outside world which will cause it to manipulate its view. If the presenter does this through an interface, it may actually use its own view as a delegate for the interface implementation, but - contrary to what you are proposing - the presenter delegates stuff to the view and not the other way around.
Doing it this way ensures, or at least makes it a lot more likely that all interaction logic stays within the presenters and does not get littered throughout presenters and views.
A view should only be manipulated by its presenter. Now of course you can reuse views in multiple presenters, but the instance of a view should only be manipulated by the presenter that instantiated it. If you expose it directly (even through whole or part interfaces), you start having to deal with a view that can be manipulated by mulitple presenters and no single presenter is in control of the view anymore.
The only code I have in the view are the notifications to its presenter of what a user has done (also known as user gestures in some MVP discussions). It is up to the presenter to decide what to do about it. I also keep all logic about which controls to enable/disable in response to user selections in the presenter and not in the view. That not only keeps all interaction logic in the presenter, but also helps towards creating unit-testable user-interfaces (forms).
