This is a major problem, a hole, in the pipeline feature. The workaround is lame: run the pipeline after modifying the jenkinsfile (in source control); kill the job as soon as Jenkins has processed the updated jenkinsfile which seems to happen right after it pulls the code at the start of the job; then run again.
I realize that this is not trivial to fix. Jenkins needs to load the jenkinsfile from source control; so it has to know exactly where to find it. For example, I usually set the git branch to a parameter so that you can choose the branch at job start time. So, to run a job, Jenkins would need to know the branch, load the jenkinsfile, then present the parameters from that file. That's alot to ask for ... since the branch may be parameter driven ... circularity.
For this, Jenkins would need to treat branch as a special parameter - not a custom parameter.
Note that azure devops does not have this problem. It loads the pipeline configuration file after you select a source branch.
A complication is that although I'm using and talking about git, there are other source control systems. So, a general purpose solution would require changes for each source control system.
Could consider a different feature that is much easier to implement, is not a good as what I describe above, but is much better than current functionality. Add a way (button) to reload the jenkinsfile params. Would need to present the existing params since one may include the branch name. Could add the button on the start job view. In addition to the (poorly named) "Build" button, add a button named like "reload jenkinsfile". It would load the jenkinsfile from source control and update the cached parameter config. The user would remain on the build start view with updated parameters.
Would the aspect that "parameters are in Jenkinsfile, but don't get used when I run the project" make this considered a bug?