Rebase-via-merge behavior difference between Linux and Windows

With the default rebase backend changing from "apply" to "merge" in 2.26, I've seen several threads about behavior changes between the two backends. This is _not_ one of those (although, as I mention at the end, the "apply" backend doesn't appear to have this issue).

Instead, what I'm observing is a behavior difference between the same "merge" backend depending on whether the command is run on Linux or Windows.

A little context: Bitbucket Server has a set of zipped repositories that provide consistent initial state, and we have tests that download those zips and then run various Git commands against them and verify we get expected outcomes. These same tests run on both Windows and Linux.

Using our merge test repository[1], one such test performs the following steps:
* Unzip bare repository
* `git clone --shared -b branch_that_differ_by_empty_commit_trgt
<unzipped> rebase-test`
* `git rebase -q --no-verify 7549846524f8aed2bd1c0249993ae1bf9d3c9998
298924b8c403240eaf89dcda0cce7271620ab2f6`

298924b8c40 is an empty commit (i.e. `git commit --allow-empty`), and is the only commit not already reachable from 7549846524f.

On Linux, when this test completes, "HEAD" in "rebase-test" is 7549846524f because the empty commit was discarded. This is the expected behavior. On Windows, "HEAD" is a new empty commit, which causes our test to fail.

If I set "rebase.backend=apply" on the "git rebase" command, I once again get identical behavior on both platforms, with the empty commit discarded. (I'm just noting this in case it's relevant.)

[1] https://packages.atlassian.com/maven-public-local/com/atlassian/stash/git/merge/2.9/merge-2.9.zip