> Moreover (since this is only available with git), it should be an extension to the git plug-in.
There's no reason at all that bisect should only be available with git. I think you're confusing the abstract concept of performing a bisect operation (which applies anywhere) with the specific "git bisect" command, which does only apply to git.
I don't think "git bisect" (the command) should be used when implementing this feature, since "git bisect" would run multiple builds within a single Jenkins build, yet doing so would not integrate this feature well into Jenkins; I would explicitly expect every build performed as part of a bisect to be a separate Jenkins job, so that any downstream jobs (e.g. tests) get triggered by each build; one may be bisecting a failure in a downstream test, not in just the build.
> These runs shouldn't really count as "builds", and shouldn't show up as such in the build history/statistics
> of the job.
Personally, I explicitly expect the opposite; if Jenkins builds a certain SCM commit, whether triggered by SCM polling, forced build, or as needed to perform a bisect, I expect that build to show up in all the normal places, and act just like any other build source.
This would hopefully allow me to look at a build's/job's history, sorted in order of SCM commits, and clearly see which commit broke/fixed the build, all irrespective of what triggered the build at each of those SCM commits.