You would expect that if e.g. a GitHub webhook is delivered mentioning a particular branch/PR commit, then Jenkins upon processing this webhook would schedule one build of that commit.

Instead, the commit identity from the webhook is essentially ignored, and the branch project is simply scheduled to be built, possibly coalescing with other near-simultaneous commits to the same branch depending on timing. When the build starts, the current branch head is looked up, to load Jenkinsfile typically, and only then will the commit be fixed for the remaining duration of the build.

It would be better for MultiBranchProject.scheduleBuild to pass a SCMRevisionAction to the build from the start in the list of actions in the Queue.Item, if it happens to know the SCMRevision (whether from a webhook or branch indexing). Furthermore, SCMRevisionAction should implement Queue.QueueAction to ensure that queue items corresponding to distinct commits are not coalesced.