I expect this to be wildly controversial, but here goes.
In LLDB we often are referring to path's on a remote host. You're remote debugging a Windows process from a Linux machine, for example. You need to be able to refer to files on the target machine by typing their paths. Currently LLDB has a TON of custom logic to do all this, and it doesn't handle all the obscure edge cases as well as LLVM does.
99% of LLVM's path handling code is already syntax-agnostic and there are literally just a handful of instructions that are platform specific. So supporting both at the same time should only increase code size by a small fraction. All of the runtime checks are trivially inlined. Path handling is hard to get right, so it's a shame we can't take advantage of the 99% not-syntax-aware code just because of the 1% that is.
Although I expect LLDB to be the biggest consumer, it seems possible this functionality could find use elsewhere. We read and write paths to and from binary files on arbitrary platforms, so it seems reasonable that someday one of these files might contain a Windows path and we try to read it on a Linux machine (or vice versa) and want to do something meaningful with the path.
All path functions are updated to take a Style argument which is defaulted to native, so existing behavior is unchanged. However, I've updated the test suite to remove as many #ifdefs as possible to prove that we can manipulate windows paths on linux, and vice versa.