I see your point, i guess it would be more effective to give $line() a uniqueID which could be a double that increases for every line. a doubles range is +/–1.7E308 so mIRC would have to be running for a heck of a long time before it actually wraps around.
This way if you need to do something based on a buffer you could log the last uniqueID and next update find which ones are new, which would still effectively let you find lines which don't trigger an event, such as an echo or output from mIRC like retrieving channel modes when you pull up chan central.
There are countless ways to wind up in an infinite loop, so i don't see how this one would really be any different besides maybe having a problem with ctrl+break.
Also bufferchange is just supposed to let you know the last line is new, and not intended to be halted or even support the ^ like how on input doesn't allow ^, only messages you might want to format yourself so I don't see people using it to change how their themes work.
Either way, this is a much needed implementation as for now the only viable solution I can think of is to filter to an alias, the alias shove each line into a binvar, and md5 the binvar to see if it doesn't match from the last check, but even that has a potential fail if the buffers flooded with the same line over and over like a timer trying to use a /draw command and filling your buffer with insufficant parameters. Afterwards comes the problem of figuring exactly which ones are new using this filter method.
Outside filter, i've had suggestions for my situation for using $line. You can't rely on $line(window,0) because of the problem with the buffer being full, line 1 is erased and the new line appended so the total amount of lines doesn't change. You can't rely on the first line or the last line by logging because that introduces possible breakage due to repeated lines. $line(window,0) works fine up until the buffer has reached its limit.
If anybody can possibly think of a VIABLE mIRC-Only solution I'd love to hear it. It MUST be with the window buffer, following the log lines is NOT an option, not everybody logs.
Another thought, would be simmilar to bufferchange which would allow you to enable custom logging for a window to log to an alias. a log file keeps track of these things and keeps appending new lines to the log file, so rather than writing to a file, it'd be unique to log to an alias.
Or rather than logging to an alias you could have an event trigger like on LOG, because then your proposed infinite loop could be countered with "echo -g window blah has changed" because -g prevents the line from being logged to file. downfall would be even if loggings off, it'd still need to trigger which would still allow you to create your own custom logging method or use the data as needed.
