@jwakely Would you agree that changing this wording to clearly require the behavior exhibited by all surveyed implementations is editorial, or do you think LWG needs to discuss the question?

I take it that, on Windows, the directory-separator \\\ is functionally equivalent to \. Do we have any facility in the filesystem library that would strip all the extra \s, to get me a short, nice-looking string?

Beyond that, this issue feels like it's possibly taking away implementation freedom, so handling this via an LWG issue appears to be preferable. Unless there is additional context elsewhere (e.g. examples) that makes the proposed interpretation the only plausible one.

For make_preferred I think this needs an LWG issue, I don't think this is the only plausible interpretation, and I have more questions.

If we did want to change the make_preferred spec as suggested, we should change the example to show a path like foo/bar//baz so we show what happens with multiple successive directory-separator characters.

The wording for make_preferred says "each directory-separator character" which is the same as [fs.path.generic] p6 step 3, which even has a note clarifying that multiple successive '/' or preferred-separator characters count as a single directory-separator. That contradicts the suggested interpretation for make_preferred.

What should path("//foo/bar").make_preferred() do? Depending on the OS, that either has two directory-separator characters at the start, or //foo is a root-name. Should / characters in a root-name be replaced with \\ ? The normalization algo in [fs.path.generic] says yes, but technically those aren't directory-separator characters, so make_preferred shouldn't change them.

If the intent for make_preferred is just something like: if constexpr (is_same_v<char_type, wchar_t>) ranges::replace(native(), L'/', preferred_separator) we should say so more clearly.

For generic_string I disagree with the description of the issue:

This implies to me that path{"a//b"}.generic_string() == LR("a/b"), since // is considered "one directory-separator" for purposes of the generic format.

I agree (except that generic_string() returns a narrow string, not a wide one).

All implementations, however, just replace every singular preferred-separator with a fallback-separator if it's defined, otherwise they return the same thing as p.string().

That's not what libstdc++ does on POSIX or Windows. It produces "a/b" in all cases. The return value is built up in stages by looking at each component of [path.begin(),path.end()) and adding explicit '/' characters between them. The actual directory separators in the native format are never examined, so there is no way for // to be preserved in the output.

The code to do that is in <bits/fs_path.h>.

I agree that Boost returns "a//b" here, but that seems like a bug. I checked the libc++ code and it is definitely wrong, that's a bug too. I think the spec is clear, but everybody got it wrong except me 😜