Freeciv

Without reading the patch too carefully: Does it handle UTF-8 correctly? (i.e. not injecting newlines in the middle of a character)

You seem to have dropped backslash handling ('\\') from make_escapes(). Is that intentional?

The other secfiles we write in addition to rulesets are the savegames and client options files. I suppose you have tested that there's no changes to how they turn out with this patch?

The main problem I have with this patch is how it selects the low-level behavior based on what the high-level entry name happens to be. That's not a good API. It's mostly a coincidence that entry name "helptext" maps to the wanted behavior (and actually it does not - like you already point out yourself, there's also "first_msg" and "cons_msg" entry names in achievements.ruleset that should match).

I don't really see why the word wrap with \n\ cannot be applied unconditionally to all strings. It shouldn't matter to high-level what the low-level's internal format is as long as thigs get returned to the high-level properly formatted. But if there IS a reason to have different behavior for different entries, then the hugh-level should have control over the behavior in a way other than selecting specific entry names.

There are a number of cases where function's starting '{' is not on a line of its own.

Any progress with this? Or can we stop blocking #1893 with this, and get at least it going?

Still haven't looked into details of this patch, but noticed that you are including fc_types.h from common/ to under utility/. That's not allowed. The whole point of separation between utility/ and common/ is that utility is independent from common. Common is freeciv specific code, utility contains utility functions that could be usable for other projects too.

There's plenty of possibilities of buffer overflow in word_wrap_helptext()
You get an static char array with 8192 characters, and write to it without ever checking if you're still within the bounds. For all we know, even the input string might already be longer than 8192.

make_escapes_quotes() has a chance of buffer overflow, and more often also chance of underusing the buffer (it will abort even if three would be space left)
The original make_escapes() reserved two bytes of extra space so that even if the very last write expand from one to two bytes there would still be space for the terminating '\0'. You add only one byte. That you decrease 'max' inside the loop does not help when we are in the last character anyway.
The decrease of 'max' inside the loop seems completely wrong in any case. You do it in addition to increasing dest, so the net effect is that for one character added you decrease the space lest by two.

The comment

  /* We free() old value only after we've placed the new one, to
   * support secfile_replace_str_vec() calls that want to keep some of
   * the entries from the old vector in the new one. We don't want
   * to lose the entry in between. */