Under "technical details" it goes into the why. What I understood is: ocaml tries to support pre-NT era strings, since that's what the console uses, but NT-era files use a different encoding, and ocaml internally uses UTF8 for everything. Since pre NT didn't handle file paths with unicode, they didn't either.

I'm not well versed in windows as to say if this was a clever way to solve the problem of console output, or if it was a really old hack that just now received some care and attention.

Because “Unicode” on windows is UTF-16, which no one except windows supports these days.

I don't think you can write a standard ANSI C program on Windows that opens a file specified on the command line where the file name contains characters not representable in whatever legacy charset Windows is using at the moment. At least that's what the situation was for many years. The article hints at some UTF8-related changes in Windows 10.

For almost every other system, the obvious code (fopen(argv[1], ...), basically) does the right thing. On Windows you have to enter some crazy non-portable parallel universe where not even the signature of main() is the same.

That's the reason why many programs don't support Unicode on Windows, despite there often being no reason for those programs to care about character encoding at all.