I tried configuring a multibranch pipeline job such that change requests have skipInitialBuildOnFirstBranchIndexing enabled. In Job DSL, it looks like this:

                buildAllBranches {
                    strategies {
                        buildChangeRequests {
                            ignoreTargetOnlyChanges false
                            ignoreUntrustedChanges true
                        }
                        skipInitialBuildOnFirstBranchIndexing()
                    }
                }

When the scan for branches runs, I get a log message on new PRs that a build was not scheduled, as expected. However, when the scan runs again, it sees that the last build was on the commit null, which is different from the current commit, and therefore a build is scheduled.

Checking PR-25 from group/my-repo and branch feature/test-new-pr
Changes detected: PR-25 (null → 4433a7512f9ccae5f8c87dc36e9ab4e95169459c+d6ee513c768b95085a34c3d6031e3be5df4aefcc)

I have jobs set up with a periodic trigger to poll for changes every few minutes, meaning that the skip initial build setting effectively only delays the build until the next scan runs. This seems to defeat the purpose of this setting.

The expected behaviour, I think, would be that no build is triggered until there is a real change compared to when the indexing first happened.