Nice improvement.

The only issue I see is that the "avoidance" part may not be clear. People may think of "task configuration avoidance" or "compile avoidance".

What exactly are we referring to avoidance here? Up-to-date checking and build caching?

I very much agree that the new message is more user-friendly. In general we assume too much about the user understanding what we mean, so more context is better.

Avoidance and parallel execution were disabled for 1 unit(s) of work during this build in order to ensure correctness, which potentially increased the build time.
Please consult the build log and deprecation warnings for more details.

"correctness, which potentially increased" reads a bit strange. I'd split that:

****** and parallel execution were disabled for 1 unit(s) of work during this build in order to ensure correctness.
This potentially increased the build time.
Please consult the build log and deprecation warnings for more details.

I don't know what to use for "avoidance" because I'm unsure myself what it refers to, but it should be explicit.

AFAIK, the three optimizations we are talking about are “Up-to-date checking”, “build caching” and “parallel execution”. These messages are already lengthy, so I tried using “Avoidance” to cover “Up-to-date checks” and “build caching”. I agree that it is awkward. I think the verbosity is better than the ambiguity when all things are considered. I'd update that.

"correctness, which potentially increased" reads a bit strange. I'd split that:

+1 on that suggestion.

AFAIK, the three optimizations we are talking about are “Up-to-date checking”, “build caching” and “parallel execution”. These messages are already lengthy, so I tried using “Avoidance” to cover “Up-to-date checks” and “build caching”. I agree that it is awkward. I think the verbosity is better than the ambiguity when all things are considered. I'd update that.

I think we should use the term "execution optimizations." This is a term that both sufficiently covers the things that are in question today and in the future, and it also captures what's important for the user (=they care that their build is executed as optimal as possible).

Note that "avoidance" rhymes with "compilation avoidance" which is not affected by validation problems.

Also note that in some cases we can't disable parallel execution (e.g. because we detect the problem too late). We could say here that "certain execution optimizations are disabled." I think it's sufficient to clarify the actual optimizations being disabled in the linked documentation.

Another thing we should probably do is to emphasize that the user can get more information (including the documentation link) for deprecation warnings by supplying --warning-mode=all.

BTW, yet another optimization that is disabled in incremental execution. We might have other things disabled in the future, too.

I’ll leave it to the execution team to resolve from here as desired.