I'm working to align the Boost.Filesystem generic path grammar with the POSIX specification. Doing so clarifies the specification of the library, and ensures that all native paths for both POSIX and Windows will work correctly. (Windows follows the POSIX conventions in some of the corner cases involved.) The particular cases involve extra slashes in paths. For example, "/foo//bar//". I was surprised to find that such a path is well-defined for POSIX and Windows, with a meaning of "/foo/bar/." In other words, multiple slashes treated as a single slash, and paths with a trailing slash treated as if a period was appended. The rules for more than two leading slashes are a bit more complex - for POSIX they are treated as a single slash, for Windows that is an invalid path. Question: what should path("foo//bar//").string() yield? 1) "foo//bar//" 2) "foo/bar/" 3) "foo/bar/." (1) follows the rule that the path string is always exactly as input. Desirable in that if a platform actually implements something a bit different from the POSIX specs for multiple slashes, implementations will behave as expected for the platform. Downside is much more complex implementation (because many more functions have to be able to cope with multiple slashes) and more complex testing. (2) Desirable in that if a platform actually implements something a bit different from the POSIX (and Windows) specs for multiple slashes, implementations will behave portably and correctly in a POSIX (and Windows) sense. (3) Desirable in that for all three options directory iteration will return three elements - "foo", "bar", "." - so it is a bit counter intuitive for the "." not to appear in the string() results. Not a strong argument. I'm leaning toward (2). Any comments? --Beman