bug#42296: 27.0.91; Correct manual entry for 'concat' w.r.t. allocation [PATCH]

[Eli Zaretskii]

> Date: Thu, 09 Jul 2020 21:51:19 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 42296@debbugs.gnu.org
> 
> That's not really what I asked for.
> 
> And how does mutability enter the picture?  We could say something
> about it (but then we'd have to be less terse), but that doesn't in
> any way replace the need to say that in many cases the value will be a
> new string, IMO.

Here's what I had in mind:

  This function frequently, but not always, constructs a new string
  that is not @code{eq} to any existing string.  Lisp programs should
  not rely on the result being a new string nor on it being @code{eq}
  to an existing string.

  When this function returns a string @code{eq] to another, changing
  the result will also change that other string; to avoid that, use
  @code{copy-sequence} on the result.

WDYT?