c++ format_to verbosity

Why are you concatenating many formatted strings?

Usually there are a few reasons I could think of, e.g. generating a web page, performing some kind of logging or similar. In that case it makes more sense to use an (output) stream, as you may not want to buffer everything in memory in the first place. You can just generate the formatted text and write it out to a socket, file or any other sink. In that case you can use the << operator for formating. Or you could keep formatting small portions of the text using format and then put them into the output stream - generally there is no need to micro-optimize at that level.

In other cases you may e.g. have a destination in a GUI with it's own "sink".

Personally I don't see any intermediate variable in your first code block that just uses the += operator and format. This is a well known method and to me it is much more readable than some self-invented method. So if there is any advantage of using such a method, it is usually offset against the next developer having to get to grips with your code.

In this case I would recommend sticking with the basics and, if applicable, streaming. Streams can still end up in a string-sink, and you can implement any buffering or other strategies that may be required (though, in C++, that can also be done with std::string itself).

To me, implementing these kind of low level functions to just get rid of a bit of syntax isn't worth it.

Overall I agree with Maarten, but here is another issue that you might face.

I have a different concern than what you expect. This way of handling string concatenation is error prone. You can easily fall into a trap if multiple strings are built at the same time. Right now, you might not need it, but in the future it could really cause issues. Keeping variable name within the generation is far safer. This will also remove the need for binding and turn your function into a simple forwarder where to parameter would be turned from string to iterator.

I'll answer the specific question:

Should I forward the parameter pack?

I'd say that you're doing the right thing here; it's the same pattern as std::format():

template<class... Args>
std::string std::format(std::format_string<Args...> fmt, Args&&... args)
{
    return std::vformat(fmt.get(), std::make_format_args(args...));
}

You wrote:

std::string str;
const auto append_format = make_append_format(str);
append_format("the answer is {}\n", 42);
append_format("what is the {}?\n", "question");

I don't see much difference between that and:

std::string str;
auto out = std::back_inserter(str);
out = std::format_to(out, "the answer is {}\n", 42);
out = std::format_to(out, "what is the {}?\n", "question");

Note that you could even omit the out = part and the code would still work — although I'll stop short of recommending that you omit it, because I think it's convenient and useful that the idiom out = std::format_to(out, ...) Does The Right Thing for other kinds of iterators too. For example, you might switch to a core-language array and pointers:

char buffer[100];
auto out = buffer;
out = std::format_to(out, "the answer is {}\n", 42);
out = std::format_to(out, "what is the {}?\n", "question");
*out = '\0';

So your make_append_format helper doesn't need to exist at all; but, FWIW, here's what I'd say about its implementation:

Pretty sure it could be constexpr (and certainly should be constexpr in C++26).

The lambda is way too arcane. You have:

return [&str]<class... TArgs>(const std::format_string<TArgs...> fmt, TArgs&&... args)
{ return std::vformat_to(std::back_inserter(str), fmt.get(), std::make_format_args(args...)); };

you should just write:

return [&](const auto& fmt, const auto&... args) {
  return std::vformat_to(std::back_inserter(str), fmt.get(), std::make_format_args(args...));
};

This gets rid of all those angle-brackets, and also the scary [&str] capture on the lambda. (Although maybe it's justified in this case, because you're returning the captureful lambda to your caller — if someone accidentally changed (std::string& str) into (std::string str), your code would keep compiling but stop working (and it would have undefined behavior). So writing the unusually verbose [&str] might arguably be a way to keep the reader on their toes here.

But, as I said, it'd be better not to have this function at all.

If you know how long the string will be, or at least an upper bound, you could first allocate the string, filling it with null characters, then write each segment to the end. You might use std::format_to_n with the address of the first null character as the buffer and the remaining number of characters as the maximum size. After appending each substring, you can extract the size of bytes written, add it to the index of the first null character in the buffer, and subtract it from the size of the destination buffer. When you’re done, you can resize the string to its correct length, then shrink_to_fit.

If you allocate enough space up front, you will not need reallocation that possibly copies the entire array, and each portion of the string will be written in place, rather than allocating a temporary buffer, writing to that and then copying from it, or else adding each character with push_back. If necessary, you could add more zero bytes to the end of the std::string when you detect there are too few left, then recalculate the address because it may have changed.