Cookie-based session management is done on a per-instance basis. This is especially troublesome when using Internet Explorer since (squeaky Steve Ballmer voice) "IE is an Integral part of Windows". So even if you've got copies of IE6 and IE7, expect some bleed-over.
Note I said per-instance and NOT per-user! Cookies aren't tied to a user ID, they're placed in a common cookie jar (not the same jar as Firefox uses, though).
I'll be willing to bet this is yet another case of DIY security where you have to log on a 2 separate users to get things done. And it's biting you, because 2 users are both binding to the same session handle (cookie).
If this isn't on my (long) list of why it's better to use container-based security instead of rolling your own, it should be. One of the things that the standard
JEE security model is based on is the idea that business processes are tied to roles. If you want to (temporarily or permanently) give the ability to perform a function to someone, you secure it to a named security role, then add that role to the user's list of allowable roles. You don't have to sign off and back on again or sign on as 2 different users simultaneously. You sign in once, and that's all. If you want' to open additional browser windows, and the app knows enough to allow for it, that's fine. Each window will also be subject to those same security constraints.