If you get forcibly disconnected, e.g. by pulling out your network cable, the signalling server will timeout the previous login after a while. That'll still happen if you use the wrong events, too - after a while it should timeout the previous user and start working again. In the meantime you should still be able to log in to a different room with a different name, because that counts as a different user, not two cases of the same user. Although off the top of my head I think there are some different flows at work here so it may depend on exactly what you're trying to do. If you think something is broken despite the fact your events are correct, as ever please file an issue following all the guidelines.
In my experience any time you try to write software that second-guesses what you're trying to do - such as silently and automatically waiting for prior operations to complete before disconnecting when you told it to disconnect immediately - you create as many problems as you solve. For example someone else will be using that action intentionally to disconnect and cancel any existing operations. Perhaps it's a way to bail out if something is taking too long and you want to timeout and return to the main screen. If disconnecting is changed to wait for existing operations to complete, you break that process, and whoever was relying on that will complain and file a bug and ask for it to be changed back. In short Construct provides the tools and it will do what you tell it, and it's up to you to make sure you tell it to do reasonable things.