Konversation is behaving correctly here on a technological level: IRC is "server as authority", i.e. Konversation doesn't dictate a nick change to the server, it asks to be given a different nick, and only when the server announces in response that one's nick has changed can Konversation assume that different nick to be its own. The corollary to that is that a server can also refuse such a request (e.g. because the desired nickname is already in use), so Konversation can't just assume it will go through and show the chosen nick in the combobox.

Since most users are unaware of that technological background, though, it might be a good idea to introduce a delay in the combobox switching that would mask what is going on to optimize for the case in which a nick change is successful. I.e. there would be no forth-and-back because the chosen nick would stick around in the combobox long enough until the server announces the nick change, at which point the combobox would show it anyway.

The downside to a naive implementation of that would be the combobox lagging behind the chat text view in case the server announces a refusal to implement the nick change (which would be shown in the chat text view). Known refusal messages (e.g. the standardized message for the desired nick already being in use) would have to feed back into the combobox and cause an immediate reset to the previous nick, adding considerable complexity to the implementation, and unknown refusal messages would still retain the lag problem. This might still be a worthwhile enterprise as time permits, however.

There currently is a delay of 20 seconds to avoid too fast nick switching so the mouse wheel triggers a channel error 438 message. I guess this confirms the issue, but is also something that would need to be implemented, moving to wishlist.