Doc: add comment about bug fixed in back branches as of 3f7323c.

While the bug I just fixed in the back branches doesn't exist in
HEAD, the requirement that MULTIEXPR SubPlans not share output
parameters still does.  Add a comment to memorialize that, because
perhaps it could be an issue again someday.

Discussion: https://postgr.es/m/17596-c5357f61427a81dc@postgresql.org

Author: tglsfdc

src/backend/executor/nodeSubplan.c

@@ -245,6 +245,21 @@ ExecScanSubPlan(SubPlanState *node,
 	 * ones, so this should be safe.)  Unlike ExecReScanSetParamPlan, we do
 	 * *not* set bits in the parent plan node's chgParam, because we don't
 	 * want to cause a rescan of the parent.
+	 *
+	 * Note: we are also relying on MULTIEXPR SubPlans not sharing any output
+	 * parameters with other SubPlans, because if one does then it is unclear
+	 * which SubPlanState node the parameter's execPlan field will be pointing
+	 * to when we come to evaluate the parameter.  We can allow plain initplan
+	 * SubPlans to share output parameters, because it doesn't actually matter
+	 * which initplan SubPlan we reference as long as they all point to the
+	 * same underlying subplan.  However, that fails to hold for MULTIEXPRs
+	 * because they can have non-empty args lists, and the "same" args might
+	 * have mutated into different forms in different parts of a plan tree.
+	 * There is currently no problem because MULTIEXPR can appear only in an
+	 * UPDATE's top-level target list, so it won't get duplicated anyplace.
+	 * Postgres versions before v14 had to make concrete efforts to avoid
+	 * sharing output parameters across different clones of a MULTIEXPR, and
+	 * the problem could recur someday.
 	 */
 	if (subLinkType == MULTIEXPR_SUBLINK)
 	{