[fs.path.generic.obs] and [fs.path.modifiers]p2, wording of `make_preferred` and `generic_*` is ambiguous

See STL issue microsoft/stl#2082.

make_preferred

The wording of make_preferred is:

Effects: Each directory-separator of the pathname in the generic format is converted to preferred-separator.

And the definition of directory-separator is:

directory-separator:

• preferred-separator _directory-separator_ₒₚₜ
• fallback-separator _directory-separator_ₒₚₜ

in other words, / and \ are both directory separators on Windows, but so are //, ///, ////, \\\\.

Thus, an implementation, given path p{"a//b"}; p.make_preferred(); could either say:

• / is a directory-separator, and / is a directory-separator, so replace each of them with \ -> p.native() == LR"(a\\b)"
• // is a directory-separator, so replace it with \ -> p.native() == LR"(a\b)"

All implementations currently take the first approach, including MSVC STL, libstdc++, libc++, and boost::filesystem.

generic_string (and other generic_* functions)

The wording of the generic format observer functions is:

Generic format observer functions return strings formatted according to the generic pathname format. A single slash ('/') character is used as the directory-separator.

(emphasis mine)

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. 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().

Start with the [fs.path.generic.obs] and [fs.path.modifiers] wording quoted in the issue, then compare the referenced microsoft/stl#2082 discussion and existing implementation behavior. Done means the standard wording unambiguously defines repeated directory separators in make_preferred and the generic_* observers, with an agreed resolution reflected in the draft.