Your recommended steps do not capture what's going on with this bug.
My general hope is that by providing a step by step example, the person reporting the bug will reciprocate with a step by step method that reproduces their issue :-)
Reading through your post: it sounds like you are using one copy of mIRC with two status windows, are connecting both status windows to ZNC using the same nickname, and ZNC in both cases is connecting to the target server using the same nickname and presumably virtualizing the second connection, since you can't connect to the same server twice with the same nickname.
Here are the new set of steps that I followed to try to reproduce your issue:
1) Install a clean copy of mIRC beta 1159 using portable mode to the documents folder with no scripts or addons.
2) Run this copy of mIRC.
3) Connect to the server using /server zncaddress:port zncnick:zncpw
4) Connect to the server using /server -m zncaddress:port zncnick:zncpw
5) Open two debug windows for both status windows
6) In status window 1, open a query window from zncnick to zncnick
7) In status window 2, open a query window from zncnick to zncnick
8) In status window 1, send a message in the query window
When I follow the above steps, I see this:
In the status window 1 connection:
a) The client sends one message
b) It then receives the message it sent to itself
c) and it receives an echo of the message
So far so good. This is what should happen.
In the status window 2 connection:
a) The client receives the message that was sent by the status window 1 connection
b) and it receives an echo of the message
(to clarify, the messages are being played back to the status window 2 connection)
As far as I can see, this is wrong. ZNC should not be sending an echo to the status window 2 connection, since that is an independent connection that has no idea about how many messages were sent by the status window 1 connection.
It looks like ZNC is treating both connections as the same connection, but that is not the case. There are two independent client connections, both of which maintain different internal states based on how they interact with the server.
