I'm not sure why there is such fervent argument about this not being a bug. The behavior is very clearly surprising, both because it defies typical behavior (there is no other place where mIRC will read data for you and then rewrite bytes without an explicit command), and because the help file explicitly contradicts the behavior, or, in its most generous interpretation, omits critical information:
The -n switch allows you to read a $crlf terminated line into a &binvar.
The help file should include a note: "The $crlf will be replaced by null bytes." If this were there, I would agree, this is an odd design, but not a bug. But with (a) no explicit description and (b) a very surprising behavior, it seems reasonable to call this a bug.
The distinction of binary and text is rather moot here. As you pointed out, protocols that mix binary and plaintext exist. In such a case, it's common to /sockread plaintext data into a &binvar to keep your code path consistent, even though you are processing plaintext. You may even still be processing across raw bytes, and not $bvar().text. Granted, you can easily work around this issue (\0\0 could be treated as a newline boundary), but nobody would expect mIRC to be tampering with the integrity of the data read across a socket.
Whether it can be fixed is another story, but the fact that you (or others) rely on this behavior does not mean it should be considered expected behavior. Attempting to convince others that a surprising behavior is normal seems odd to me. Surely you understand that any routine that reads data from a pipe and silently modifies that data
violates the principle of least surprise?
The term "bug" or "not bug" is a gray area, it depends on an arbitrary line. At the end of the day, "bug" is used to communicate the idea that something needs to be changed. In this case, the thing being communicated is that this behavior is confusing and should be adjusted, either via code or by adding a note in the help file. Something legitimately needs to be changed. Priority and method of fix are up for discussion, but this is a legitimate report.
