As I mentioned- Khaled has replied to this issue before (once in the very thread you linked to in your initial post). His stance is the same each time.
But to reply to the issues the ircd devs raised:
Nobody is saying that the server *must* do conversion for user data. If you encounter another client using CP you can simply tell them to switch to Unicode. mIRC 6.35 supports unicode, as well as every IRC client ever. The issue you reported had to do with
network services and network messages using extremely old encodings that no sane OS or application uses anymore. They don't need to implement any form of encoding conversion or touch iconv at all-- they simply need to provide their server messages in a more appropriate encoding for 2010 (yes, it's 2010). If they can't do this-- well, they shouldn't really be hosting an IRC server.
mIRC 6.35 was the "backwards compatibility" phase of your x86 analogy. It supported codepages and Unicode alike. That phase is over and nobody moved on. Following on that analogy-- we're in a 64bit-only world now and those ircd developers still haven't rewritten their applications. Following your analogy further, 32bit compatibility layers in x86 arch won't stick around forever. Eventually 32bit code won't run anymore, just like eventually CP encodings won't work anymore. We're not there *YET* (mIRC 7 is
still a beta), but it's coming.
You reported an issue, but you didn't report a
bug. As the
beta page states, the lack of CP support is
by design. This release is to inform developers to update their code-- not the other way around.
PS. IRC isn't dead.
