Some of Freenode's servers reply with RPL_AWAY on every PRIVMSG to a user who is away at the time. RPL_AWAY may also be sent in response to a /whois command. Konversation used to only display RPL_AWAY when it was expecting a response to a /whois command, due to the automatic request system. Right now, it always displays RPL_AWAY. Most likely the automatic request check fails due to InputFilter::getAutomaticRequest() making use of operator[] on QMap, which has changed semantics in Qt 4 to auto-insert a default-constructed item when the argument is not found in the map. This has potentially far reaching consequences in our protocol handling, as getAutomaticRequest() is used all over the place. I find it worthwhile to document this here as we've been perenially unhappy with how the automatic request system works and this issue brings to light a whole bunch of really subtle decisions to make, such as how to handle RPL_AWAY outside of a WHOIS context.
The behavior of the operator doesn't appear to have changed since Qt 3 in this case after all. The new behavior wrt/ the away messages might actually be the result of a fix vs. the KDE 3 version: The code made no explicit attempt to hide repeated identical away messages, but would have had to for correct behavior (to handle cases when the message should be shown again, such as when it has changed, or when the user has returned and went away again in the interim - which would need a special periodic auto-WHO in case there are no shared channels with the discussion partner or channel auto-WHO has been disabled by the user). So if it hid them, the cause for that might have in fact been a defect. Finally, it's also possible that it's actually the ircd that has changed its behavior. Closing.