In the sequel, I shall refer solely to strfmon(), but everything applies equally to strfmon_l().
The mechanism by which the locale data is made available is not material to anything in this defect report.

The following defects are ordered in decreasing order of importance, as I see them, except with some related issues grouped adjacent to one another.
All defects (except probably the last) should be corrected however.

1. 
   When issue 0001199 was fixed (the changes made as the result of that I generally agree with) one part of the original issue report seems to have been forgotten.
   It (0001199) said:
   

   
   However, without a distinction between positive and negative values, and without a visible decimal separator, this behaviour is useless, or even dangerous
   

   
   

   
   The issue with positive/negative was (mostly) handled, the issue when there is no visible decimal separator was not, and needs to be.
   See issue 0001199 for an example illustrating the problem.
   

   
   
2. 
   

   
   Following on from the previous, it is also unclear, even with the text as amended by issue 0001199, what should be done when a locale defines non-empty strings to be used as the signs, but specifies the same string for both cases.
   This is effectively the same problem as issue 0001199 dealt with, being unable to determine whether a value is positive, or negative, just in a different way.
   

   
   Relevant to this, and what makes it different from the empty string case, is that the result might differ when the position of the sign string is different for positive and negative values.
   That is, it is not necessarily simply invalid to use the same non-empty string for both the positive and negative signs.
   

   
   
3. 
   

   
   It is not always clear in the specification when character means character and when it means byte or perhaps "character from a restricted character set", or something different entirely.
   

   
   That the specification generally means character is clear from line 69523:
   

   
   The format is a character string, beginning and ending in its initial state, if any, ...
   

   
   which would make no sense if character was being used as a synonym for the C programming language char data type, or simply a byte, or even a character from the Portable Character Set from the standard (XBD 6.1).
   Those kinds of characters have no state, hence no initial state to require.
   

   
   This issue crops up in many places, the most obvious is in (line 69540):
   

   
   An '=' followed by a single character f which is used as the numeric fill character.
   

   
   The text (lines 69541-69542) attempts to add some meaning to this:
   

   
   In order to work with precision or width counts, the fill character shall be a single byte character; if not, the behavior is undefined.
   

   
   But that makes no sense at all.
   To work with the precision and width counts, the fill character needs to occupy one column position in the output.
   That distinction has nothing at all to do with how many bytes are in the representation of the character.
   A single byte character, in some locales, might be zero-width or occupy multiple columns in the output, even in a constant width font.
   Obvious examples are the <tab> character, and ASCII control characters.
   A <newline> or <carriage-return> would have different, but related, issues.
   It is also unclear why the behaviour should be undefined should the application not give a suitable character as the fill character value.
   That is a truly machiovellian punishment.
   Would it not be better to simply make it clear than in such cases the intended alignment might not be able to be achieved?
   That is, the implementation should just use whatever character is specified as f when needed as the fill character, and if that character is not suitable for the purpose, the output will look odd, instead of nice.
   No calling abort(), or removing all of the user's files, which "undefined behaviour" would permit.
   

   
   A similar problem can be found at line 69577:
   

   
   A decimal digit string w specifying a minimum field width in bytes
   

   
   which also makes little sense, if one assumes as the specification seems to imply, at a minimum, that the objective is to be able to align output from multiple calls to strfmon().
   What matters is the appearance of the final output, not how many bytes of encoded characters are needed to achieve that result.
   The number of bytes is, or should, only be relevant when determining whether the result fits within the maxsize number of bytes available in the output buffer.
   Everything else should be using characters, possibly constrained in some cases to be printing or graphic characters, and perhaps sometimes constrained by the widths of the characters concerned.
   This needs to be clear in the specification, with no mention of bytes in any of the relevant places.
   

   
   The same problem arises with everything else inserted into the resulting output string, including the mon_decimal_point and the <mon_thousands_sep> strings.
   Lines 69592-69594 do explain the idea:
   

   
   To ensure alignment, any characters appearing before or after the number in the formatted output such as currency or sign symbols are padded as necessary with <space> characters to make their positive and negative formats an equal length.
   

   
   though that text does give rise to the immediately following defect.
   

   
   It should also be made clear what other constraints, if any, must be met for the output to be able to be nicely aligned.
   The use of a monospace (constant width) font to display the result is an obvious one, without that achieving alignment requires much more complex mechanisms that simply counting characters, which is all that is available here.
   But is it expected that all the values intended to be able to be aligned have neen formatted using the same locale, or is it intended that output from different locales be able to be intermixed, and remain aligned?
   The answer to that question constrains what constraints should be placed upon what is permitted in locales for the mon_decimal_point (I have a fake locale, for testing purposes, which uses $'\u3002' as that character, and the font I use for my terminal sessions renders that character in 2 columns).
   Is strfmon() expected to work with such a value?
   It does, even to aligning (approximately) as intended, as the alighnment is primarily for the value to the left of the radix, which is unaffected by this.
   But something similar might be used as the mon_thousands_sep.
   Further, different locales might have different mon_grouping settings.
   My fake locale uses "2;3;2;3;2" which is going to result in a different number of separators being inserted in some values than the more common "3".
   As one call to strfmon has no way to communicate decisions to another, nor to predict what locale might be in use when the next call is made, it might seem necessary to constrain the alignment goal to apply only as long as the same locale is used for all relevant strfmon calls.
   But that might also be too strict, perhaps as long as the locales used all use the same mon_grouping, and use as their mon_decimal_point and mon_thousands_sep strings which occupy the same number of columns as the equivalent setting in all other locales used in a sequence intended to align correctlty, that would be enough?
   

   
   Did no-one ever consider any of these questions?
   

   
   
4. 
   

   
   The text at lines 69592-69594:
   

   
   To ensure alignment, any characters appearing before or after the number in the
   formatted output such as currency or sign symbols are padded as necessary with
   <space> characters to make their positive and negative formats an equal length.
   

   
   concentrate entirely upon making the positive and negative output forms of equal length, but the text at lines 69582-69584:
   

   
   This option can be used to keep the formatted output from multiple calls to the strfmon( ) function aligned in the same columns.
   

   
   makes it clear that the aim that is implied by lines 69592-69594 is not sufficient to meet the expectations of the strfmon specification, and that more precision is required to meet the overall objective.
   

   
   That is, if for positive numbers, the sign follows the value, and for negative nnumbers the sign precedes the value, then, to keep the numeric parts of a positive and a negative value aligned, both of them must allocate space in the resulting
   string for the possible negative sign before the value, and the possible positive sign following the value (when positive signs are being included), so that either of them might be used to occupy the sign value.
   What's more, that is what implementations I have seen actually do.
   Simply having the positive and negative formats being of equal length is not suffficient.
   

   
   It is also not stated anywhere, but clearly is intended (I hope), that the expected alignment is only achieved if the same format string is used for all the applicable calls to strfmon().
   

   
   
5. 
   

   
   A corollary to the previous two points, is that it should be made explicit that aligned values can only be expected to remain aligned when displayed or printed, if they are rendered in a constant width font, or at least one in which all characters are represented in a non-negative integer multiple of a fixed column width.
   

   
   
6. 
   

   
   The description of "grouping characters" (a term for which incidentally I can find no definition in the standard, though it is obvious that in this context it means the mon_thousands_sep characters inserted to perform the grouping function of monetary output values, which is a defined operation) and how they apply to the Left Precision given in lines 69589-69590 is one of the least useful specifications I think I have ever seen.
   It states (lines 69589-69590):
   

   
   If grouping has not been suppressed with the '^' flag, and it is defined for the current locale, grouping separators are inserted before the fill characters (if any) are added.
   

   
   The pre-conditions are simple enough, but I would interpret the action as meaning that each "grouping separator" (another undefined term) inserted replaces one (or perhaps more) of the fill characters, which then fill in any remaining unused positions as specified in the previous paragraph (lines 69581-69588).
   The subsequent sentence (line 69591), which ends the paragraph, about the inapplicability of grouping to fill characters, even if they are digits, is clear enough as it stands.
   

   
   But as illustrated by the examples (see lines 69640-69642 (or 69643-69645 or 69646-69648) in comparison with lines 69649-69651 which, apart from the use of a non-space fill character in the alternatives of the former, which is immaterial, show the same example, except the former has grouping enabled, and the latter with it suppressed), and from observing what is done by actual implementations, that is not what is intended at all.
   Rather, the value given by the Left Precision "n" value, is to be increased by the maximum number of "grouping separators" which would be needed if a value to be formatted generates n (as specified) digits before the radix character (decimal-point) if any.
   Then the value is formatted, and the number of "grouping separators" required for the actual value are inserted, and finally the increased value of n is used to fill any remaining unused positions with fill characters.
   That is, the use of grouping can increase the number of fill characters to be used for a particular value, and the actual left precision width from what is in the conversion specification, but never decrease it, compared to when grouping is not used.
   

   
   How, an implementer, or an application writer, is intended to determine the intended behaviour from the written specification bamboozles me.
   It needs rewriting.
   

   
   Note also, that though the linux manual page for this function attempts to make this clear, it is not a lot better:
   

   
   Next, there may be a left precision of the form "#" followed by a decimal digit string.
   If the number of digits left of the radix character is smaller than this, the representation is padded on the left with the numeric fill character.
   Grouping characters are not counted in this field width.
   

   
   That would make it seem as if the number of grouping characters inserted, or which might be inserted, has no effect on the padding inserted by the left precision, which is not correct either.
   
   
   
7. 
   

   
   The ERRORS section at lines 69628-69630 states the functions shall fail if:
   

   
   
   • [EINVAL]
     

     
     The '+' flag was included in a conversion specification and the locale's positive_sign and negative_sign values would both be returned by localeconv( ) as empty strings.
     

   
   
   
   

   
   The APPLICATION USAGE section, at lines 69672-69676:
   

   
   The '+' flag should be used with care, because if the locale's positive_sign and negative_sign values are both empty strings, there is no way to distinguish negative from positive values with signs and therefore strfmon( ) fails. If the application has a preference for signs but parentheses are acceptable, it should try strfmon( ) with the '+' flag first, and if it fails with [EINVAL] then repeat the call without the '+' flag.
   

   
   and the RATIONALE at lines 69678-69680:
   

   
   The [EINVAL] error condition applies only when the '+' flag is used because this flag indicates that the application requires the use of signs, and if there are no signs in the locale data then this requirement cannot be satisfied.
   

   
   together expand upon this intended unique use.
   

   
   While implementations are generally permitted to add error numbers, and to add meanings to errors the standard specifies, as specified by XSH 2.3 at lines 17831-17833:
   

   
   Implementations may support additional errors not included in this list, may generate errors included in this list under circumstances other than those described here, or may contain extensions or limitations that prevent some errors from occurring.
   

   
   that same section goes on to place a restriction upon this implementation freedom, at lines 17839-17841 (and following for more restrictions not relevant here):
   

   
   Implementations may generate error numbers listed here under circumstances other than those described, if and only if all those error conditions can always be treated identically to the error conditions as described in this volume of POSIX.1-2024.
   

   
   

   
   Taken together all of this implies, to me anyway, that the implementation may not generate EINVAL for any error other than the one listed, as an application would then be unable to ascertain that the problem was the '+' in the format string, and offer a different format for the locale in question in that case.
   

   
   The problem all this causes for the implementation, is just how it should deal with applications which fail to meet their shall obligations, for example the one at line 69529:
   

   
   The application shall ensure that a conversion specification consists of the following sequence:
   

   
   I appreciate that when an application fails to comply with its obligations, implementation behaviour is unspecified, or perhaps even undefined, and is certainly beyond the scope of the standard.
   This however does not help the implementer, who must do something in such cases.
   Further as it seems above, the implementer is prohibited from using the obvious EINVAL error code in such a situation.
   Further, it does not help the application writer either, if some implementations simply ignore such issues and continue formatting as best they can, others return -1 and a seemingly random error code, and yet others simply call XSH 3 section 3/abort (pages 577-558).
   

   
   At the very least, the specification should offer some guidance in this situation, and probably rewrite the application usage and rationale, so as to no longer constrain EINVAL such that it cannot be used by the implementation for other issues.
   

   
   
8. 
   

   
   The standard offers no guidance on what should be done, should some of the data expected to be provided by the locale, is not defined there.
   The POSIX locale is one which does not supply any.
   Particularly after the resolution of issue 0001199, some of this has
   been dealt with, but not all.
   This includes the lack of a (non-empty) mon_decimal_point.
   There is also no discussion on what should be done if any of the specified strings are non-empty, but do not contain anything which produces a visible representation in the output.
   

   
   There should be.
   

   
   
9. 
   

   
   Returning to APPLICATION USAGE section, at lines 69672-69676:
   

   
   The '+' flag should be used with care, because if the locale's positive_sign and negative_sign values are both empty strings, there is no way to distinguish negative from positive values with signs and therefore strfmon( ) fails. If the application has a preference for signs but parentheses are acceptable, it should try strfmon( ) with the '+' flag first, and if it fails with [EINVAL] then repeat the call without the '+' flag.
   

   
   That suggests that simply omitting the '+' flag, will cause stfrmon() to use parentheses as the indicator for negative values.
   That is not what the post-issue 0001199 standard causes to happen.
   Instead, as stated on lines 69567-69571 when considering the case that
   neither of the '+' nor '(' flags are included in the format:
   

   
   If the style cannot be determined from these locale values because a value that needs to be used would be returned by localeconv() as {CHAR_MAX}, the style used shall be that specified for the '+' flag; if this would cause strfmon( ) to fail because the locale's positive_sign and negative_sign values would both be returned by localeconv( ) as empty strings, strfmon( ) shall behave as if the negative_sign value was the string "-".
   

   
   In other words, unless the format specifies the '(' flag (in which case this section is never reached, and its positive_sign and negative_sign and sign placement values are all ignored), if the '+' flag is not given, and the locale's default is not to use parentheses to indicate negative values, then the resulting output would use the empty positive_sign if the value is non-negative, and use "-" instead of an empty negative_sign if the value is negative.
   
   
   This APPLICATION USAGE text needs to be rewritten to take that into account.
   
   
   
10. 
    

    
    At times the standard is too specific in what it specifies.
    For example, at lines 69557-69558:
    

    
    If a sign's placement cannot be determined from these locale values because a value that needs to be used would be returned by localeconv() as 0 or {CHAR_MAX}, ...
    

    
    Why is it important what the issue is with the value?
    

    
    The range of values for the sign position are 0 to 4, with 0 not being useful for the situation being discussed in those lines, or {CHAR_MAX} to mean no value is supplied.
    But what if the locale data specifies a value of 7?
    That has no (currently) defined meaning, and hence is not useful for determining the placement of the sign, but it is not "returned by localeconv() as 0 or {CHAR_MAX}", so what is the implementation to do?
    

    
    This kind of over specification should be removed, it is not important why the sign placement cannot be determined from the locale values, just that it cannot.
    Note that this is not just a fanciful, perhaps even imagined, impossible case.
    A later version of the standard may add extra possible values to any of the fields for which a set of numeric designated choices are provided, and an older implenentation (an instance of stfrmon compiled into an existing applicaion for example) may encounter a previously invalid value, and needs to know how to handle that case.
    This is not an instance where "behaviour is unspecified" (or even "undefined") is an acceptable outcome.
    The standard must be permitted to evolve without invalidating existing applications.
    

    
    
11. 
    

    
    The EXAMPLES section, page 2132 (lines 69632-69670) assumes the existence of "a locale for the US" and, to make sense of the example output, what that locale must contain.
    I can find no justification in the standard to assume that such a locale exists anywhere.
    I certainly believe that most readers would understand USD as the international currency symbol for the United States of America, and $ as its national currency symbol, and probably that its frac_digits and int_frac_digits would usually both be two.
    I am not sure however that using a "-" to indicate negative values, and nothing for positive ones, rather than enclosing negative values in parentheses, or use of CR for positive and DB for negative, is how such a locale would be defined.
    Nor would I necessarily expect the sign, if used, to precede the currency symbol, rather than follow it.
    

    
    If some fictional locale is to be used for examples, regardless of whether that locale might be an actual locale on some system used by one or more of the actual writers of the text, then at least as much of it as is needed to understand the examples should be presented in the specification.
    

    
    Further, there should certainly be examples given where the POSIX (aka C) locale, the only one the standard actually specifies, is used.
    Had there been, some of the problems this specification had before issue 0001199 rectified them, and some of the problems it still has, might have been recognised and corrected much sooner than this.
    

    
    
12. 
    

    
    The DESCRIPTION at lines 69524-69526 contains:
    

    
    ..., and conversion specifications, each of which shall result in the fetching of zero or more arguments which are converted and formatted.
    

    
    "Zero or more" ?
    
    
    
    
    The zero case is obviously for the %% format conversion specification (which I personally would not treat as a conversion specification at all, but as an escaping mechanism, but that isn't the point here).
    
    
    
    
    But "or more" ??
    
    
    
    
    One is certainly more than zero, and one (exactly) is what every other format conversion requires.
    Why not just say "zero or one", and not leave the reader wondering when more than one might be required?
    Of course, if there is some hidden intent to allow indirect specification of the field width, the left precision, or the right precision, or some or all of those, in the way that the printf family of functions permit, which would perhaps be a useful addition, though not supported by any implementation of which I am aware, then the "or more" would be justified.
    
    
    
13. 
    

    
    In the same paragraph as the previous defect (lines 69524-69526) the text elided at the beginning of the text quoted previously is:
    

    
    The format is a character string, beginning and ending in its initial state, if any, that contains two types of objects: plain characters, which are simply copied to the output stream, ...
    

    
    but there is no definition anywhere of what is a plain character.
    The intent is obvious, but standards should not rely upon readers being able to deduce from what appears to be obvious, they should be explicit.
    
    
    
14. 
    

    
    The locale specification (XBD 7) and the specification of strfmon seem to lack the ability to format currency amounts in the (old style to be sure) formats previously used in the UK, and other countries including AU and NZ.
    That is, the Lsd format, as in £10/- or £9-19-11 and similar constructions.
    There may be other formats in use, or previously in use, which are similarly neglected.
    

    
    There is also no way to specify that other characters, rather than '(' and ')' be used to surround values, further it should be possible to have different characters surrounding positive and negative values - the positive_sign and negative_sign settings cannot be used for this, as only one of them is ever used for any particular value, and whichever that is is only ever used once.
    

    
    These issues should be fixed, but this is not the place to do it.
    Thus I will not offer potential solutions - the issue is here just so it is clear that the problems are known, and cannot at some future time be dismissed with "We didn't ever consider those possibilities."