If you have a Jenkinsfile that uses properties to define parameters with default values, as of JENKINS-35698 you can use params.XXX syntax to pick up the default value if the build was not explicitly triggered with parameters—for example, the first build of a pull request. But if you then edit the default value and push that commit, the second build will continue to use the original default. It is only the build of the third commit which actually picks up the default defined during the second build.

This seems to be because ParamsVariable gives precedence to a ParametersAction defined on the build. Unfortunately after the first build defines the ParametersDefinitionProperty, when the second build is scheduled by ParameterizedJobMixIn.scheduleBuild2, a ParametersAction is added with the default values (from the first build). ParamsVariable has no way of differentiating this case from the case that something (like Build with Parameters) specifically offered particular values.

Filing in workflow-cps as that is where ParamsVariable is implemented, though workflow-job defines JobPropertyStep, workflow-multibranch is the normal reason you would be defining parameters like this, and core is responsible for the dubious behavior.