Thank you for the explanation. I understand now: global variables initialized by environment variables cannot change their type when a new value is assigned. In former plugin versions they could change e.g. from string to boolean. Now I have to assign the boolean to a different variable. Otherwise the boolean type would be ignored.
I can live with that change, but it was a bit confusing, because within the Groovy script one cannot distinguish between a global variable and an unqualified parameter. The difference becomes clear only within the context of the pipeline configuration.

dkarr This is my understanding based on the comments above and the release notes of the Pipeline Groovy Plugin

Parameters are passed into the run as environment variables and are captured in a params object. This means there are three references to that parameter value:

env.foo
foo
params.foo

The first two return that environment variable that was set. This has to be a string because it is an environment variable. The third method retains the parameter type set because it is not used in the environment. In this case:

This functions as expected because it is a boolean param

properties([parameters([booleanParam(defaultValue: false, description: '', name: 'foo')])])
if (params.foo) {
    echo "true: $foo"
}
else echo "false: $foo"

But this will not because it is a string from environment variable:

properties([parameters([booleanParam(defaultValue: false, description: '', name: 'foo')])])
if (foo) {
    echo "true: $foo"
}
else echo "false: $foo"

So then, in general, if the name of a pipeline parameter specified in the job configuration is "foo", then referencing it in the body of the pipeline script as "foo" will get a variable of a type equivalent to what is specified in the job configuration, EXCEPT if the type in the job configuration is "Boolean Parameter", which will result in a String type. In that case, referencing it as "params.foo" will always guarantee that it will be provisioned as a type that is equivalent to what is specified in the job configuration, including a "Boolean Parameter". Under those circumstances, would you conclude that it would be reasonable to document this understanding in the pipeline documentation?

I would say that it is a best practice to always use the params object if you want the ensure that the type is consistent. Referencing the parameter as either foo or env.foo returns the value as it was injected into an environment variable and will always be of type String.

properties([parameters([booleanParam(defaultValue: false, description: '', name: 'foo')])])

echo "foo: " + foo.getClass().toString()
echo "env.foo: " +  env.foo.getClass().toString()
echo "params.foo: " + params.foo.getClass().toString()

returns:

[Pipeline] echo
foo: class java.lang.String
[Pipeline] echo
env.foo: class java.lang.String
[Pipeline] echo
params.foo: class java.lang.Boolean
[Pipeline]