Adding a non-trivial system abstraction to your code - be it a file system or a socket/networking API - is always a tricky task, even for the simplest of requirements. For example, Windows API is inherently UTF16, so if you want good performance, you need to keep all your filesys references in wstirngs. But not on Windows, you'll need strings instead. If you are to abstract this, you have a choice of either using an opaque "filesystem_string" type that maps to wstring/string (with an API for cross-conversion) or defining, say, an UTF8 API and then doing a boatload of run-time Unicode conversion on Windows. The fun part is that while this makes the filesystem code more compact, it has a negative effect on the rest of the application. The app will either need to deal with conversions to/from "filesystem_string" when serializing/displaying them or the abstraction layer will be busy converting utf8's to the native string format. Either way you pay with performance for "portability".
This doesn't apply to just this new C++ TS. It's the same issue with the existing standard POSIX API as well (fopen/fread/etc). It's great for hacking together something that builds on Linux, BSD and Windows, but you'd typically want to put in your own system interface before shipping production version.