Overall looks good but we need to fix escaping in the standard and the implementation before this ships. Also a bunch of minor(ish) comments inline.

One minor comment inline otherwise looks great. Much more readable than template operator()!

Next I want to look at the std::back_inserter<std::string>.

I'm actually surprised how fast this issue went through LWG :-)

One check less, yay!

Nice improvement but I'd still recommend exploring direct writes to contiguous containers as discussed on the other diff.

Nice improvement! It would be good to clarify in the standard that omitting parse is allowed for user-defined types. Could you open an LWG issue?

Mostly looks good but at least one output doesn't look right which suggests an error in width estimation. Also a few nits inline.

LGTM

Looks great! My main suggestion is to rename __parser into something more appropriate (see an inline comment) and possibly separate the actual parsing logic from the parser output.

In general looks good but I would strongly recommend not to instantiate all of formatting path just to validate width/precision (see an inline comment).

LGTM, just one minor comment inline.

LGTM

Looks much better, thanks. A few comments inline.

LGTM

Can you explain why you dislike this approach?

You could do much better by having a single array and storing the type alternatives for the common case of small(ish) number of arguments in an integer. This is essentially what {fmt} does. I think the current implementation is based on Microsoft's which I'd strongly discourage.

Great work, @Mordante! Can't wait to use more of std::format on gobolt.

LGTM

Same as D110495:

As commented, I'm very skeptical about this approach because it has extra buffering for common cases but I defer to libc++ maintainers the decision whether they want to land this as is or optimize buffering now.

Overall looks good, just a bunch of minor(ish) comments inline.

As commented inline, to_chars is not a great API for implementing this because you have to do extra work to reparse the output. But it's probably OK for the initial implementation.

LGTM

LGTM

Overall looks good but I think there is a potential buffer overflow in format (see inline comment).

But I consider that an issue in to_chars and not in <format>.

All parts of the paper have been implemented

LGTM

In general looks good, just a few minor comments inline. However, the discussion in earlier diffs may affect __formatted_size_buffer API.

LGTM provided that the extra copy and buffering is eliminated in the follow-up diffs. Not directly related to this diff but I recommend doing something about the default codegen (see the inline comment).

Character-by-character output, especially type erased one introduced in D110494 doesn't seem efficient. As commented on the the previous diff the buffer and corresponding output iterator should provide access to a contiguous buffer and type erase the reallocation, not character output.

Since there's no guarantee every container's insert behaves properly

In D110495#3082114, @Mordante wrote:

I've created a proof-of-concept here with benchmark results D112361.
That revision is just to show what I did. It's intended to be a basis for the changes, it *is not* to be used as-is.

I'm very surprised that this is the solution you went with. Indirect function call to write each character individually will likely be slow in practice compared to a contiguous buffer and a bulk copy. Please post benchmark results.

Now that the format context is almost always format_context, it might be worth adding [[clang::preferred_name(format_context)]] to the basic_format_context template.

Minor comment inline, otherwise LGTM.

LGTM

LGTM

Two minor comments inline, otherwise LGTM.

Looks good, thanks for addressing the comments.

LGTM

Some nits inline, otherwise LGTM.