Proposed resolution:

This wording is relative to N4892.

1. Modify [format.string.std], Table [tab:format.align], as indicated:

   Table 59 — Meaning of align options [tab:format.align]

   Option	Meaning
   <	Forces the field to be aligned to the start of the available space. This is the default when the presentation type is a non-arithmetic typefor non-arithmetic types, charT, and bool, unless an integer presentation type is specified.
   >	Forces the field to be aligned to the end of the available space. This is the default when the presentation type is an arithmetic typefor arithmetic types other than charT and bool or when an integer presentation type is specified.
   […]

[ 2021-11-29; Daniel comments ]

This issue touches the same wording area as LWG 3644 does.

[ 2021-09-20; Reflector poll ]

Set priority to 2 after reflector poll.

Victor said "It mostly looks correct but I think the wording needs a bit more work because we don't mention arithmetic presentation types anywhere."

The alignment options specified in [format.string.std], Table [tab:format.align] causes an inconsistency when formatting characters. The output differs depending on whether an integer is formatted using a character presentation type or when using a character directly:

format("{:3}", '*'); -> "*  " // aligned at the start of the available space
format("{:3c}", 42); -> "  *" // aligned at the end of the available space

I expect both calls to return the same value: "* ". The current wording mixes the type and the presentation type. To me, it seems clearer to adjust to wording to only use the presentation type. Another approach would be adjusting the wording to add an exception when an integer type uses the character presentation.