Ah, I didn't realize this affected files as well. That said, I'm not entirely sure I agree-- I think that one could go either way. On one hand, a user might expect a file dump to be verbatim raw data, on the other hand, as I mentioned regarding windows, the debugging output is mostly meant to visualize the data, not necessarily provide it for copy paste purposes-- that's the flipside of the argument though.
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)
Users might get confused either way. Especially if they /loadbuf'd a debug.log into a window and it was raw byte data, because that would not display accurately inside mIRC. A discrepancy between "/debug file.log | loadbuf @debug file.log" and "/debug @debug" might be confusing.
This is an argument for a /loadbuf (and /savebuf) switch that reads/saves to the file as ASCII instead of as UTF-8. Of course, mIRC can't actually actually display ASCII anymore, 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.
Similarly, users might get confused by reading a file.txt and seeing different data from a @debug window, and, depending on their editor, it might be parsed as utf-8 anyway, which would defeat the purpose of visualizing the data.
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. mIRC shouldn't be making any assumptions about what you will do with the debug.log, or even that you will open it in a text editor. Even if you do open it in a text editor, many do NOT have the same limitation as mIRC and can open the file as ASCII or UTF-8 by simply selecting a different option. Even Windows Notepad can do this!
