Bisect marking new commits incorrectly

In trying to do a bisect on the Git repository, I seem to have come across surprising behavior where the order in which `git bisect` appears to forget that previous commits were marked as new.

You can see this behaviour in the following commands, run on the Git repository, where the order of the `git bisect new` commands affects the results.

Case 1:

    $ git bisect start; git bisect old v2.15.0

    $ git bisect new 95a731ce
    Bisecting: 40 revisions left to test after this (roughly 5 steps)
    [934e330c9d0d12f7a0dd82b9699456c891e4dd4a] Merge branch 'ad/5580-unc-tests-on-cygwin' into maint

    $ git bisect new 14c63a9d
    Bisecting: 153 revisions left to test after this (roughly 7 steps)
    [421f21c98f8b515412ca683ae3743013a8b3bda2] Merge branch 'js/mingw-redirect-std-handles'

    $ for h in 95a731ce 14c63a9d; do git log -1 --format=oneline --decorate "$h"; done
    95a731ce92c7576d927f0d8a9b27c206cb58c2e6 (origin/maint) Almost ready for 2.15.1
    14c63a9dc093d6738454f6369a4f5663ca732cf7 (origin/master, origin/HEAD, refs/bisect/new) Sync with maint

Case 2:

    $ git bisect start; git bisect old v2.15.0

    $ git bisect new 14c63a9d
    Bisecting: 153 revisions left to test after this (roughly 7 steps)
    [421f21c98f8b515412ca683ae3743013a8b3bda2] Merge branch 'js/mingw-redirect-std-handles'

    $ git bisect new 95a731ce
    Bisecting: 40 revisions left to test after this (roughly 5 steps)
    [934e330c9d0d12f7a0dd82b9699456c891e4dd4a] Merge branch 'ad/5580-unc-tests-on-cygwin' into maint

    $ for h in 95a731ce 14c63a9d; do git log -1 --format=oneline --decorate "$h"; done
    95a731ce92c7576d927f0d8a9b27c206cb58c2e6 (origin/maint, refs/bisect/new) Almost ready for 2.15.1
    14c63a9dc093d6738454f6369a4f5663ca732cf7 (origin/master, origin/HEAD) Sync with maint

As you can see, in both cases, only the most recent "new" command appears to have any effect. I'd have expected that both commits would have been marked as "new", and the bisect run would use both facts to work out which commit is the target of the bisection.

This is using v2.15.0. It's possibly relevant that 95a731ce is a direct parent of 14c63a9d.

Is this a bug, or intentional behaviour? Am I missing something that means it's actually sensible to have Git silently discard some bisect commands in this sort of circumstance?