Abstracting the framework useful for contact-centric email

I am actually modifying the open-source webmail software Roundcube to provide the contact-centric functionality described in the posts below as a personal research effort. The developers of Roundmail deserve huge credit for producing a free piece of software that is remarkably well architected.
Nevertheless it's clear that, like all email software that I have come across, Roundcube is currently constructed around a few fundamental assumptions that then constrain the way the product is used. In particular Roundcube is designed with the assumption that you are interacting with an email folder or the address book, but never both. From the screenshots in my earlier posts below I will leave you to decide whether you are looking at a list of emails (i.e. a folder view) or a contact entry (i.e. a contact view), the point being that contact-centric email merges the concepts.
With conventional email, a folder view will typically allow you to filter and/or sort your emails, so you can certainly arrive at a list of emails to or from a given individual, and from a typical email addressbook you can usually click a button that will take you to a 'compose' form to send an email to that individual, and Roundcube includes these capabilities as does Thunderbird, Outlook, and most other email user applications.
The development of contact-centric email would actually benefit from a more abstracted framework within which the component panes could be relatively independent, but respond to messages or events sent between them.

At the most basic level, clicking on a folder or contact in the left pane will cause the 'items list' pane to update with a new list of items, and the 'item preview' pane to update if a contact has been selected. Clicking on an item in the 'item list' pane will cause the 'item preview' pane to update.
Using a single-window view, the 'item preview' pane could be minimized, maximized of left adjustable within the window. The default for the size of the preview window could be adjusted for different events, e.g. clicking on a 'compose' button might maximise the preview pane (which would then also be in 'edit' mode for an email) and the same could be done if an 'edit' button were clicked while viewing a contact entry.
Particularly in the case of clicking on a contact in the 'contacts list pane', it could be imagined there are multiple types of items that could be listed in the 'items list pane', including items from systems other than an email platform. If the framework supported tabs, and general support for web content within each pane, then it is conceivable the contact-centric solution could be extended outside the email context. For example, if this contact makes documents available in Google Docs to the user of the email client, then those documents could be listed on another tab in the 'items list pane'.