That is basically intended behavior, because Konversation always errs on the side of caution when it comes to claiming that a person named X is the same person that was named X previously. For example, query tabs will show when people leave IRC when that information is available (because you share some channel with them), but it won't show when they return, because there is no secure way to claim that it's actually the same person.

Services authentication theoretically does allow to make that claim, but is racy already in the query example - we'd have to WHOIS first and wait for reply to find out the person is authenticated, and the person could talk before we get the reply. With the join example that's even more problematic - delaying showing the join until we have established identity would easily throw off the proper ordering of events in the display.

You can make the argument that it should work naively nickname-based, and I don't entirely disagree, because clearly the feature would be more useful then in the common case. The security aspect also isn't as critical as in the query scenario, because in a query you might tell someone some secret information, but a join is at least one more step removed from that (e.g. opening a query). We'll think about it, but it's not easy to get past the queasy feeling of doing something insecure by making it nick-based.

I somehow doubt that someone will use Konversation's optional feature of showing a person's comings and goings only if they were active for some malicious intent. It's too rare an occurance. First, you need to know that the victim is running Konversation; second - that he's got that non-default option turned on; third - that he would trust someone on IRC anyway. There are many easier methods of forgery. Plus, it's easy to intuit that just because Konversation said that somebody left and then somebody joined with the same nick (even with the option turned) it doesn't guarantee that it's the same person. It doesn't know any more than you do.

Still, I see your point.

Also, the option explicitly states: "Hide Join/Part/Nick events except for nicks active within the last..." - it doesn't say for active PEOPLE, it says for active NICKS. Seems straightforward for me: if someone with that nick said something within the last (period), that nick's comings and goings are displayed. Konversation doesn't imply that it will make sure it's the same person, so I would argue that even if Konversation knew it were a different person with the same nick and hid his joining the channel because of it, it would still be technically a bug because it would do something that conflicts with what the option says literally.

Right, that's a pretty good argument.

(Comment #3, that is. :)