I think users expect it to do what it says it does in the help file: "Outputs raw server messages, both incoming and outgoing, to a debug.log file, or a custom @window." (emphasis mine)
You emphasized the wrong thing. "raw server messages" does not imply how the data will be displayed (in fact, messages rather than data implies that it's not meant as a packet sniffer). Outputs is the keyword here. And there are a lot of different ways to output data. One of them is to display each byte separately in a hex editor fashion as I described above. You can say that a hex editor "outputs raw data in an exe file", but you won't expect to see a copy pasteable version of the bytes in the file.
but the "workaround" of UTF8-encoding the text first, then outputting that to a window, produces the same result visually -- which is fine by me seeing as this is already what it does with /debug.
Except this is not true. Your assumption is that the raw data being dumped to a file is UTF-8, but this is not always the case. Many times, you will get ANSI encodings in the file, which will garble when /loadbuf'd back to mIRC, so it won't produce a correct result visually. Part of the reason /debug does not encode the data before displaying it in @debug is to allow users to visualize the raw results of different encodings:
44./debug windows now show raw text without interpreting multibyte or utf text.
The reason for this change was specifically because users were unable to see proper data in the @debug window for non-UTF-8 channels, since the data in @debug will be garbled by the transcoding. This is important in 7.x, since mIRC has no other way to see non-UTF-8 text. The goal is to
not have the same garbled output in a channel, and allow users to see what was
meant to be sent. The keyword, again, is "see", not use.
You seem to be stuck on assuming that the purpose of the command is to "visualize" the data, but that's just one purpose. There are other valid uses for /debug and it doesn't make sense to limit its usefulness.
No, I'm assuming that when piping debugging output to a window or file, your goal is to visualize the data. Again, you can use /debug -i if you have a custom purpose, so the usefulness is NOT limited in all cases, you just have to use /debug -i instead. I don't see a problem with doing that, especially given that the "other valid uses" I can think of are edge cases.
If you can name a specific use case for /debug file that requires the explicit raw data to be shown, I'm all ears-- but I can't think of anything "useful" besides staring at data. Note that even a tool like Wireshark doesn't display "raw data", it's shown in the same uncopyable "hex editor" form I mentioned above.
