So, I just wanted to confirm a few things relating to this feature request.
First, there seems to be 2 slightly different use cases relating to branch indexing as I see it. The first use case is when there is a multibranch pipeline job configured with branch indexing which then loads a Jenkinsfile containing a git() build step pointing to the same git repository as the Jenkinsfile itself but with customized polling options. The other use case is when there is a multibranch pipeline job configured with branch indexing but the polling options are configured directly in the multibranch pipeline job itself and not in the Jenkinsfiles being indexed. The second use case seems like a more focused and isolated (and perhaps simpler implement) variation of the first. This improvement seems to be focused on the former use case, but I think we need to consider the latter use case as well. Does this sound reasonable?
In regards to the second use case I just mentioned, there currently doesn't seem to be any way to filter branch indexing triggers in any way even though similarly configured non-multibranch pipeline jobs provide several such options (ie: "Polling ignores commits with certain messages", "Polling ignores commits from certain users", etc.). If I am understanding correctly, this difference in behavior appears to be intentional due to some technical limitation in git. Could someone clarify what this technical limitation is exactly? Is it that the git toolset requires a workspace in order to perform this filtering? That doesn't seem to hold true for non-multibranch pipelines since the polling operation applies before the source repository is checked out (or at least it seems this way based on my crude understanding of the mechanics involved).
Perhaps as a first step someone could look into adding support for basic branch indexing filters to multibranch pipeline jobs themselves and then perhaps look to extend that behavior to support further customizations from the indexed Jenkinsfiles.
If you think these 2 slightly different use cases are independent enough to warrant their own feature requests I'd be happy to create a new one for the second use case and link it to this one instead.