Multiple chats sessions with same contact in S4B window ?

First, let me say 'thanks' to everyone for patience on this.  I know that this is a frustrating experience in the UI.  Unfortunately, the timeline for a fix that I had original expected has not worked out.  We are not ignoring the issue, nor are we declining to fix it because of Teams.  

In the latest Insider release, we have an improvement that prevents multiple windows if a conversation is open in a separate window.  (Show conversations in separate windows is enabled in Preferences, or you have double-clicked an item in chats to pop out a window.)  In this case, we will reuse the same, open window for all conversations with that contact.  This does not prevent multiple entries in the Chats list for the same contact.

Since this has been a long-running discussion, and people have asserted various solutions over time, I will offer some context on the issue and our efforts to resolve it.  

The fundamental problem is that Office Communicator/Lync/Skype for Business conversation model is session-based, not people-based, so every conversation between two people is distinct and stored independently in the conversation history in Exchange.  This has been true since the original Office Communicator product, and the entire ecosystem is built around the architecture.  Rearchitecting the entire product ecosystem is not feasible. (Note that Skype consumer service uses a completely different back end that was built independently when Skype was it's own company.)

The Chats list in the app shows the conversation history where you see multiple conversations sessions with the same person.  The problem comes in that the Chats list also acts as a tabbed "switcher" for conversations.  As a conversation history, it's fine.  As a switcher, it is not.  (Note that in the Windows SfB app, the conversation history and tabbed list of open conversations are separate so this confusion doesn't happen.)  Our efforts to mask the underlying session model have exposed various issues that made the proposed solution unstable, perform poorly, or not work correctly in various scenarios. 

We are continuing to look at how we can best address this issue.

Phil Garding