>> You operate on a level of the entire messages flow. Forums, chats and web 2.0 networks are trying to make conversations feel as lightweight and barrier-free as possible.
... caught my eye. I manage a team of younger developers for whom real time chat is simply the way they grew up interacting. Everyone is signed into hangouts and "operating on a level of the entire messages flow" (sic) all day long. A large part of the interaction is off topic, vague, and ineffective. Here's an example from yesterday...
Dev 1: the repo url is wrong, I'm getting a 404.
Dev 1: wait, might be a typo.
Dev 1: my bad.
Everyone on the team received this message and presumably stopped their current mental task at least long enough to read it, as I did. In the end it had no impact whatsoever. The developer clearly should have thought through his problem before notifying the entire team that he had one. But this is how chat is used.
I've tried very often to get them to be more deliberate in chat communications, without any success. I have also tried to encourage complicated topics to move quickly to voice hangouts, with even less success. Streams of real time chat messages remains the primary way the group interacts, to the point where I have backed off my efforts and come to the conclusion that I'm likely the one who has to change.
That said, there will always be a need for deliberate communications within organizations. Email grew up as an analog for letters and memos, which served as deliberate, archived, time-stamped records of an important communication. They were considered, usually minimal (because they took effort to create), and got to the point. They were events, not streams of ephemera. I'm not sure that this constant buzz of chats does a good job of replacing that. So for that reason the sentence "You operate on a level of the entire messages flow" doesn't make me smile.
1) giving E-Mails more inherent structure that is managed centrally (streams) instead of by each user (filters, folders).
2) making E-Mail more synchronous instead of asynchronous.
As far as I understand, you're arguing against (2). I agree with everything you wrote, however I still find (1) a very good idea. It is also an idea that IMO could be implemented entirely without changing the protocol - it's just a question of where you put this additional information. Streams could also simply be represented as a group address in the CC field that is managed differently by their client/server architecture, but otherwise fully downwards compatible.