Protocols Modify State External to Session
The fundamental issue is that the protocol modifies state that's external to the session. In the case of forum sharing, the external state is the list of forums and their visibility; in the case of introductions, it's the contact list. If multiple sessions can modify the same external state then we may have problems keeping the sessions consistent with the state and with each other.
When we first thought about sessions, I was thinking of the sequence of messages and the local state stored by the protocol - I didn't think about external state. That's also the reason the ProtocolEngine interface doesn't provide a way to update external state (#376 (closed)). For any protocol that updates external state, such as the forum sharing and introduction protocols, we need to re-think what a session means.
I think we can solve this issue in the general case by saying that all sessions that affect the same external state must share the same session ID and local state. In other words, a single ongoing session per unit of external state. Then we need to design the state machine to allow for the fact that different parties may try to perform different operations within a given session, possibly at the same time. This will probably make the state machine more complex, but that's because the state machine now captures the possibility of multiple operations affecting the same state, whereas previously we just sort of crossed our fingers and hoped that didn't happen.
To put this in more concrete terms, the unit of external state for forum sharing is the visibility of a given forum to a given contact, so all sessions that affect the visibility of a given forum to a given contact should share the same session ID and local state. In particular, if a contact shares a forum with us and we simultaneously share the same forum with them, both sessions should use the same ID. When we receive their invitation we'll look up the session and discover that we're in the "invitation sent" state. We can then have a rule in the state machine that says what we should do if we receive an invitation in that state. For example, we might apply the Alice/Bob tie-breaker and ignore one of the invitations, or we might decide that we should react in the same way as if the contact had accepted our invitation. But the point is, the need to handle that situation is defined as part of the protocol.