Hi Beman, I have been thinking about the interface exposed by Boost.Filesystem a little. As I said earlier, I base my experience on trying to write portable code that runs on both windows and **nux, at a minimum. I sympathetic to the view that the most efficient underlying representation must be used, but I'm not convinced we can have that 100% while making the interface portable and easy to use. Therefore I think the main interface should focus on being portable, and if someone want to optimize stuff, they can dig into the native parts of the API. Recoomandation 1: Make two typedefs: string_type and native_string_type where the first is portable and the second is not. Recommendation 2: the default sting constructor should take an std::string and assume this contains utf8 unless the system does not support it; then it simple assume the native code-page. This implies that windows code neeed to convert to utf16 in this constructor. (The same can be said about other constructors/append; the presence of these constructors makes it harder to write portable code). Recommendation 3: if users wants to go native, which means non-portable by default, it might be more explicit to add path::fromNativeString(...) to create a path this way. Remark 1: the interface for string is quite hard to grasp, and I fail to see why it's needed. There are 11 functions! Recommendation 4: remove the c_str() function, it can easily be called from a string return. Recommedation 5: the interface only needs 2-4 string functions: string_type string() const; // perhaps with different OS return type const native_string_type& native_string() const; The first will return in utf8, thus requiring a conversion on e.g. windows; the second is not-portable, but guaranteed to require no conversion, The first converts \ to /, the second does not. Recommendation 6: for efficiency, comparison operators can be overloaded for one argument of the type string_type and native_string_type. just my 2 cents kind regards Thorsten