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 for non-arithmetic non-pointer 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 for arithmetic types other than charT and bool, pointer types or when an integer presentation type is specified.
   […]

   [Drafting note: The wording above touches a similar area as LWG 3586. To help solving the merge conflict the following shows the delta of this proposed wording on top of the LWG 3586 merge result]

   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 non-pointer type.
   >	Forces the field to be aligned to the end of the available space. This is the default when the presentation type is an arithmetic or pointer type.
   […]

[ 2022-02-10 Approved at February 2022 virtual plenary. Status changed: Tentatively Ready → WP. ]

[ 2021-10-14; Reflector poll ]

Set status to Tentatively Ready after seven votes in favour during reflector poll.

According to [tab:format.type.ptr] pointers are formatted as hexadecimal integers (at least in the common case when uintptr_t is available). However, it appears that they have left alignment by default according to [tab:format.align]:

Forces the field to be aligned to the start of the available space. This is the default for non-arithmetic types, charT, and bool, unless an integer presentation type is specified.

because pointers are not arithmetic types.

For example:

void* p = …
std::format("{:#16x}", std::bit_cast<uintptr_t>(p));
std::format("{:16}", p);

may produce " 0x7fff88716c84" and "0x7fff88716c84 " (the actual output depends on the value of p).

This is inconsistent and clearly a bug in specification that should have included pointers together with arithmetic types in [tab:format.align].