Improve P/R as recommended by SG16 (including their optional change)

Author: Dani-Hub

xml/issue4070.xml

@@ -67,15 +67,12 @@ For a non-escaped string, we want the ill-formed sequence to be
 formatted as �, which the proposed resolution tries to ensure.
 </p>
 
-
 <note>2024-05-08; Reflector poll</note>
 <p>
 Set priority to 2 after reflector poll.
 </p>
 
-</discussion>
-
-<resolution>
+<superseded>
 <p>
 This wording is relative to <paper num="N4981"/>.
 </p>
@@ -115,6 +112,71 @@ transcoding of a formatted `path` when `charT` and `path::value_type` differ
 </blockquote>
 </li>
 
+</ol>
+</superseded>
+
+<note>2025-06-11; SG16 comments and improves wording</note>
+<p>
+The "and not converting from `wchar_t` to UTF-8" wording added in the index of implementation-defined 
+behavior by the current proposed resolution should be changed to "and the literal encoding is not UTF-8".
+<p/>
+It was noted that "the literal encoding" is ambiguous in both the normative wording in 
+<sref ref="[fs.path.fmtr.funcs]"/> p5 and in the new wording quoted above. In both cases, the intent 
+is to refer to the "ordinary literal encoding". However, some SG16 participants were reluctant to include 
+a drive-by fix with the proposed resolution for this issue since the ambiguous literal encoding reference i
+s a pre-existing and separable issue. Those same SG16 participants were more concerned that the same 
+wording was used in both <sref ref="[fs.path.fmtr.funcs]"/> p5 and in the corresponding entry of the 
+implementation-defined behavior index. I would defer to the LWG chair to decide whether to address this 
+as an additional related clarification with this change or as a separate editorial or LWG issue.
+<p/>
+The minimal change is to replace "and not converting from `wchar_t` to UTF-8" with "and the literal encoding 
+is not UTF-8". The optional change is to insert "ordinary" before "literal encoding" as well. Once that is done, 
+I'll have SG16 confirm they are content with the new proposed resolution.
+</p>
+</discussion>
+
+<resolution>
+<p>
+This wording is relative to <paper num="N5008"/>.
+</p>
+<ol>
+<li><p>Modify <sref ref="[fs.path.fmtr.funcs]"/> as indicated:</p>
+
+<blockquote>
+<pre><code>
+template&lt;class FormatContext&gt;
+  typename FormatContext::iterator
+    format(const filesystem::path&amp; p, FormatContext&amp; ctx) const;
+</code></pre>
+<blockquote>
+<p>
+-5-
+<em>Effects</em>:
+Let `s` be <code>p.generic_string&lt;filesystem::path::value_type&gt;()</code>
+if the `g` option is used, otherwise `p.native()`.
+Writes `s` into `ctx.out()`, adjusted according to the <i>path-format-spec</i>.
+If `charT` is `char`, `path::value_type` is `wchar_t`, and the literal encoding 
+is UTF-8, then the <del>escaped path</del> <ins>(possibly escaped) string</ins>
+is transcoded from the native encoding for wide character strings to UTF-8
+with maximal subparts of ill-formed subsequences substituted with
+<span style="font-variant:small-caps">u+fffd replacement character</span> per
+the Unicode Standard, Chapter 3.9 <span style="font-variant:small-caps">u+fffd</span>
+Substitution in Conversion.
+If `charT` and `path::value_type` are the same then no transcoding is performed.
+Otherwise, transcoding is implementation-defined.
+</p>
+</blockquote>
+</blockquote>
+</li>
+
+<li>
+Modify the entry in the index of implementation-defined behavior as indicated:
+<blockquote>
+transcoding of a formatted `path` when `charT` and `path::value_type` differ
+<ins>and the ordinary literal encoding is not UTF-8</ins>
+</blockquote>
+</li>
+
 </ol>
 </resolution>