On Windows and OS X, you can work with paths in Unicode.
Do you have a reference for a good source of information about OS X handling of paths?
Here is a good tech-note on the "new way" vs. the "old way": <http://developer.apple.com/technotes/tn2002/tn2078.html> You can get to a Unicode path (encoded as UTF-8) from an FSRef through FSRefMakePath, or through CFURLs which seesm to be the preferred way of working with any kind of locator (file-based or not) on OS X.
Is there progres toward a wchar_t-aware path?
Yes. I now have the outline of a design for the internationalization of Boost.Filesystem paths. The C++ committee meets in Sydney, Australia, next month, and the LWG will be queried to see if they are interested in the standardization of an internationalized version of Boost.Filesystem based on that design. If so, I'll start work on a prototype.
I'd love to see it, and help in any way I can. IMO, filesystem::path is somewhat useless for I18N-aware applications. Linux might be the center of the universe to some, but I18N is extremely important on Windows and Mac, and they have both adopted Unicode. But, I think it could be made usable simply by supporting wchar_t strings. I am happy with having the onus of dealing with the long paths themselves in file operations or UI on my end - I don't need to wait for long path support in the C++ library, since I can implement the custom open myself.
I notice the existing posix checks would fail horribly in this case. Is a UTF-8 checker in order?
It wouldn't hurt. Care to contribute one?
I could probably be talked into it. On the other hand, it path supported wchar_t strings, it would be much more straightforward to deal directly with wchar_ts.