Fun fact: most MS kernels, including DOS, supported "/" as a path separator. They were just filtered out of the command lines by the argument passing code.
There was a system call which would tell the argument parser that you wanted a different switch character, and if you changed it to, say, "-", then "/" would work. Of course, not everything used the standard argument parser, so if you did change this you ended up in a world of pain because your tools would start behaving inconsistently, but it was theoretically possible.
I've seen references to this code existing as late as XP, but I don't do Windows any more, so can't comment on later versions.
In terms of file path, windows seems to always support \\ or /, both in API or in software like Explorer. That's still true for Windows 10.
That leads to some interesting answers on stackoverflow sometimes about cross compatibility, where the correct answer of "use whatever constant your language has for directory separator" gets down-voted in favor of "use forward slash everywhere".
Many applications assume \ and deal with paths directly, instead of using the Windows APIs for path manipulation.
This means the moment your application gives a / to another application, there is a high probability that it will break, regardless of what the Windows API supports.
But a path in windows is very unlikely to start with / ... went through some serious pain trying to pass the command options to a windows program from a bash script last night in fact, so it's very fresh in my memory.
There was a system call which would tell the argument parser that you wanted a different switch character, and if you changed it to, say, "-", then "/" would work. Of course, not everything used the standard argument parser, so if you did change this you ended up in a world of pain because your tools would start behaving inconsistently, but it was theoretically possible.
I've seen references to this code existing as late as XP, but I don't do Windows any more, so can't comment on later versions.