1. Corrected the target window of incoming echo-messages
Well, technically there was nothing to correct in this case, as the echo-message support in mIRC was behaving correctly.
However, I did add a hack/kludge, outside of the echo-message code, to handle ZNC's method of mirroring/relaying messages to a client that did not originate the sending of a message.
If you test this, does it look like the issue is resolved?
2. Prevented these messages from triggering text events
Yes. In previous versions of mIRC, non-standard messages received from ZNC were triggering events that, by design, were intended for messages addressed to you.
ZNC is sending messages to you that you have sent to other users, so these messages should presumably not be processed in the same way as messages where you are the target, eg. stripping control codes, ignoring messages, flood protection, replying to ctcps, replying to sound requests, applying the lock option that disables incoming messages, and so on, all of which are being applied before scripts events are triggered.
The on OPEN/TEXT/ACTION/NOTICE/SNOTICE/CTCP events, likewise, were intended for messages addressed to you, and that is likely how most scripts use them.
I could make it so that the above non-standard messages continue to trigger these events, however the onus would be on the script to check the source/target combinations. Or I could add a new identifier, such as $invalidmsg, so that a script knows exactly when mIRC is treating the message as non-standard.
To round things out, if mIRC receives a non-standard message with a source/target that are both other users, which again should normally never happen, it will display these in the status window, just in case.
