Proposed resolution:

This wording is relative to N4971.

1. Modify [ostream.formatted.print] as indicated:

   void vprint_unicode(ostream& os, string_view fmt, format_args args);
   void vprint_nonunicode(ostream& os, string_view fmt, format_args args);
   

   -3- Effects: Behaves as a formatted output function ([ostream.formatted.reqmts]) of os, except that:

   1. (3.1) — failure to generate output is reported as specified below, and

   2. (3.2) — any exception thrown by the call to vformat is propagated without regard to the value of os.exceptions() and without turning on ios_base::failbitbadbit in the error state of os.

   […]

In section [ostream.formatted.print], bullet 3.2 there is a mention of badbit:

any exception thrown by the call to vformat is propagated without regard to the value of os.exceptions() and without turning on ios_base::badbit in the error state of os.

Now the affected functions vprint_unicode and vprint_nonunicode are specified to behave as formatted output functions ([ostream.formatted.reqmts]), which distinguishes two phases:

1. Output generation, which would call setstate(ios_base::failbit) in case of a failure (which may throw an exception)

2. The actual output itself, which would call setstate(ios_base::badbit) in case of an exception

The vformat call is obviously part of the first phase (since it generates the output sequence and not yet the actual output), and any failure here (such as an exception) would under regular formatted output function rules set ios_base::failbit and not ios_base::badbit (the latter would indicate a loss of the actual output sequence integrity and is therefore set by the second phase in case of an exception).

Therefore mentioning ios_base::badbit in (3.2) doesn't really make sense, it could only meaningfully refer to ios_base::failbit instead.