There must be some misunderstanding of the issue I've reported. Otherwise, I can't imagine anyone would take this stance.
The root of the issue is that if a session is initiated by any mechanism or via any client that session WILL be closed at the time any other session is closed by any mechanism or client that is initiated by the same user (same account).
That is counter intuitive behavior and is inconsistent with almost all other session management schemes in place by other "systems", vendors, providers, etc. I believe for good reason.
If you simply think of this in an OOP paradigm you can see that this is very awkward. Forgive my pseudo-code You are suggesting that given sessions.sessionA and sessions.sessionB, sessions.sessionA.endSession() results in sessions.sessionB.endSession(). Something like sessionManager.invalidateAllUsersSessions(sessions.sessionA.user);
Or you are stating that sessions.sessionA == sessions.sessionB is true. Such that sessions.sessionA.endSession() == sessions.sessionB.endSession().
Is there another explanation? Why is this in any way necessary? As a non default feature of session management you may wish to provide that as an option. As default behavior for all sessions it is disruptive to normal operations.
Now, to the Comment from Michael Knight about handling stolen laptops and also using privacy mode on the client. Wonky!
In the case of a stolen "client", you have introduced a security issue with this "feature". If the thief were to change my profile contact email and password and then logout of their session then I would be logged out and have no knowledge of the new password or any ability to reset it (email has been changed in the profile).
Nice Security! Its not just session hijacking now, its account hijacking.
Further, that "privacy mode" should in anyway be a part of session/security management mechanism is scary! You are suggesting that we should rely on the client to adequately "forget" the session. That is bad practice from a security perspective as well as from a server side resource utilization perspective. You would intentionally leave a session open that a "hijacker" could still access even though the original user (session initiator) believes the session is closed. In terms of resources, the server will keep those sessions (and all the related state) available long past the usefulness of the session. Expanded that usage out over multiple users and multiple sessions this would result in a highly inefficient use of resources.
Please escalate this to a high priority BUG and fix as soon as possible.
With all users upgraded to Atlassian account, new logout behaviour ensures you only log out of your current session. Only in case of password reset, users will be logged out from all active sessions.