Thanks for your bug report. I am afraid I have little experience with ZNC, so I cannot say why this would happen. The beta has simply added support for IRCv3 echo-message. The support for echo-message is an IRCv3 server-side setting that causes the server to echo messages back to confirm delivery of sent messages.
From what I understand, it can also be used to replace the ZNC self-message feature and can be used by the znc.in/playback feature?
That said, znc.in/playback appears to have been superceeded by IRCv3 "chathistory". Most clients from this point onwards are supporting IRCv3 as a standard instead of ZNC-specific features, so this may require changes to scripts.
Upon upgrading to v7.68.1100 I was met with dozens of old messages (from/to myself), which were processed by my open/text scripts. It was not very nice for all those new browser tabs to open and begin beeping.
Is this a setting that you have enabled in ZNC? To send mIRC a chat history on connect? How is this working in v7.68? Are you using a script to parse these messages in v7.68?
Are you using a self-message script like the one mentioned on the
ZNC Query Buffers page that links to
this self-message script page?
Update: I have just tested v7.68 and v7.68.1100 with ZNC and its query buffer feature. In v7.68, ZNC only plays back messages you received from others. In v7.68.1100, with echo-message enabled, ZNC also plays back messages that you sent. That is what you are seeing, which means that you would need to update your script to handle those messages as well.
This is the same issue as when users first tried to use ZNC with the self-message and playback features - you needed to use a script to correctly handle the custom ZNC messages.
Update2: I tested again using a beta that enables support for parsing ZNC self/playback messages into appropriate windows. This is code that I decided -not- to include in the v7.68.1100 as I was concerned it would interfere with existing ZNC scripts but as ZNC is doing its own thing here with echo-message, I thought I would test out the code. The code specifically changes how mIRC handles PRIVMSGs that have your nick as the source and a different nick/channel as the target. A client should normally not receive these types of messages. However, some services, eg. ZNC, can send them. In my beta, mIRC will now display these as if sent by your nick in the appropriate query/channel window.
Unfortunately, it's not that simple.
The PRIVMSG parsing routine handles at least ten different PRIVMSG contexts, and supports many features, eg. updating the IAL, triggering notify, resetting idle time, playing sounds, speaking text, triggering script events, flood protection, CTCPs, ignoring lines, stripping control codes, updating tab history, etc.
The playback buffer that ZNC sends to mIRC on connect includes messages that you have already received as well as messages that you have not yet received.
The messages that you have already received have previously triggered all kinds of events. But since you are now receiving them again, they are triggering those same events again.
The message you have not yet received are triggering events as expected.
As mentioned in various places on self-message / znc.in/playback / chathistory documentation, a client needs to remember the timestamp of the last message it received in order to know the difference between messages it has already received and new incoming messages, so that the client can handle these differently. This means mIRC would need to save the timestamp of the last message received for every query/channel and to process messages arriving after this timestamp as new messages, and messages before this timestamp as old, already-received messages.
It's also not clear whether messages with your nick as source and a different nick/channel as target should trigger the above events, since these are technically messages that you have already sent to someone else.
