模式本身并没有真正规定如何处理这个问题。
我个人的偏好是一个消息/事件中心，在那里演示者可以注册对某些事件的兴趣。它避免了复杂的依赖关系树，并保持演示者可测试。
例如：

class PresenterA
{
   void HandleProductSelectionChanged(int productId)
   {
      EventHub.Publish(EventType.ProductChanged, productId);
   }
}

class PresenterB
{
    void PresenterB
    {
       EventHub.Register(EventType.ProductChanged, HandleProductChanged);
    }

    public void HandleProductChanged(object state)
    {
       var productId = (int)state;
       var productDetails = LoadProductDetails(productId);
       view.DisplayProductDetails(productDetails);
    }
}

EventHub将保留一个订阅者列表，以便为每种事件类型调用。
您保留了可测试性-只需访问HandleProductChanged，查看PresenterB如何响应新的产品选择。
唯一的缺点（和任何模式一样）是引入了间接层。如果PresenterA直接调用PresenterB，或者PresenterB监听PresenterA上的事件，那么会发生什么是显而易见的。
在这种方法中，您需要额外的步骤来查看EventType.ProductChanged，然后查找哪些Presenter注册了对该事件的兴趣。
根据我自己的经验，这种单一级别的间接性非常值得模块化。

就我个人而言，我不同意许多人选择事件巴士来解决这类问题的方式
我很难想象两个主持人需要相互交流的情况，你能提供一个真实的案例吗？
在我看来，如果两个演示者需要相互交流，那么你应该将这两个演示者合并到一个演示者中。记住，两个用例之间的模型对象的交流也是业务逻辑，所以演示者的范围可能比你最初想象的要大。
同时也要考虑到，如果你以正确的方式使用协作者，那么你就不需要在演示者之间进行交流，数据应该由协作者提供。

我想补充一下我的观点，我有一个移动的开发背景。
在我看来，您正在处理一个典型的Master-Detail场景。我的建议是，尽管容器A和B有它们自己的Presenters，因为显然它们可能有它们自己的实现作用域，需要以一种干净的方式处理，他们不应该直接交谈，他们可以没有彼此而活，但是如果有一种方法可以同时呈现他们--它将通过一个更大的容器来处理它们。这是你问题的关键。
声明通知容器A/B更改的接口。在更大的容器（我们称之为主机）中实现它们，并创建一个侦听器来表示这些接口以绑定通信。
每当容器A中发生变化时，它通过接口通知主机，主机将事件传递给它自己的呈现器，呈现器可以运行更大范围的操作，如存储状态或将分析事件发送到后端，最后它告诉主机更新容器B被给予用于更新的数据的细节。
带有事件的解决方案可能非常诱人，我自己也做过很多次，但是它是有代价的。如果你滥用它，你只会增加技术债务。我建议在“事件”不一定绑定到任何特定处理场景的情况下使用这种机制，但可能会成为你项目中其他模块的兴趣点。