This is inspired by hashicorp/terraform#37463, which I think proposes a good compromise that is equally applicable to OpenTofu.

OpenTofu's human-oriented plan output currently includes a short summary of what all of the different change icons mean:

OpenTofu used the selected providers to generate the
following execution plan. Resource actions are indicated
with the following symbols:

  + create
  ~ update in-place
  - destroy
+/- create replacement and then destroy
-/+ destroy and then create replacement
 <= read (data resources)

I added this a long time ago in response to hashicorp/terraform#14379, where someone noted that we weren't previously explaining anywhere what these symbols mean.

hashicorp/terraform#37463 points out that we also use the "icon" -> to delimit the current and planned values for the "update in-place" case, but the meaning of that is not explicitly described anywhere.

Proposal

In this issue I'm echoing the proposal from the other linked issue, which calls for adding a few extra tokens to the end of the ~ update in place line to concisely summarize the change notation:

OpenTofu used the selected providers to generate the
following execution plan. Resource actions are indicated
with the following symbols:

  + create
  ~ update in-place (current -> planned)
  - destroy
+/- create replacement and then destroy
-/+ destroy and then create replacement
 <= read (data resources)

This makes things a little more explicit without greatly increasing the verbosity of the output.

The current implementation of this part of the output only includes the subset of actions that actually appear in the plan, and I don't propose to change that: the additional (current -> planned) would appear as part of the description of ~, and so would appear only if there's at least one update-in-place change in the plan.

I note that this does have an annoying edge-case because we also use the ~ and -> notation as part of describing the per-attribute effects of +/- and -/+ changes, but we don't include the ~ update in-place line in that case. That isn't a new problem -- we already don't mention what ~ means in this case -- and so I don't propose that we try to do anything about it here.

If we find that bothersome then we could address that in a separate change (outside the scope of this issue) which searches deep inside each action to find out if there will be any nested ~ symbols inside any of the action descriptions, but that'd be a far more invasive change to the plan renderer.