This won't work. Since I have around of 10 different script that are programmed not to interfer each other, I have to change every of this script. And I think it would be the same with other users.
The fact that you will need to update your scripts does not mean "it will not work". Updating scripts to work with 7.1 was entirely expected and documented during the betas. I don't see having to update your scripts as a blocker in itself.
But and event in any script must be catched and translated to own script that uses iso-characters. And in situations without user-interaction (i.e. the autojoin-list in many nickserv-implementations), I have no chance to detect the charset.
We're not talking about full compatibility for chatting purposes. Your concern was that an admin was unable to properly manage a server. /raw -n allows you to send commands to manage a server. As I already mentioned, improved scriptability will likely come in future versions, but this is a fine start.
The only way to solve this would be a kind of low-level-events that cannot be overridden and used to translate between the charsets. But this translation should be the part of the client, not of any user-script.
I'm not too sure what you mean by this, or why this is the only solution. This also is starting to sound more like a feature suggestion than a bug report.
As I said before, if it is possible to create an inconsistent state, the client has an error - not the user or the server. Nettalk for example hides any iso-channels when I enables utf-8-support. That's not what I excpect, but it's better than an inconsistent state and - that's the point - I have the choice to enable or disable it.
Define inconsistent state. I don't see mIRC introducing inconsistent state here. There is an inconsistency in the way mIRC data from the server, but the state itself is fine. mIRC joins a utf-8 encoded channel-- the problem is that it joins the wrong channel, not that the state is inconsistent. If you'd like, mIRC could hide these channels, but this is beside the OP's point. The issue is about getting mIRC to communicate with the ANSI-encoded channel, not about whether the channel should be listed.
