GitVersion [Bug] Merging develop to release branch makes alpha version jump back

Describe the bug

Hello again dear GitVersion maintainers :)

When getting the changes from the develop branch on top of an existing release branch, the commit counting of develop drops as the Merge Base commit changes.

Expected Behavior

The commit counting on develop should never drop, otherwise this generates overlapping build numbers.

Actual Behavior

    [Test]
    public void MergingDevelopToReleaseBranchShouldNotResetCommitCounterOfDevelop()
    {
        using var fixture = new EmptyRepositoryFixture();
        fixture.MakeATaggedCommit("2.0.0");
        fixture.BranchTo("release/3.0.0");
        fixture.BranchTo("develop");
        fixture.Repository.MakeCommits(8); // on develop
        fixture.AssertFullSemver("3.1.0-alpha.8");

        // work on a beta release
        fixture.Checkout("release/3.0.0");
        fixture.Repository.MakeCommits(20);
        fixture.AssertFullSemver("3.0.0-beta.1+20");

        // Finalize beta
        fixture.ApplyTag("3.0.0-beta.1");
        fixture.AssertFullSemver("3.0.0-beta.1");

        // and start new one
        fixture.Repository.MakeCommits(2);
        // Counting commits from MergeBase of develop and release/3.0.0
        // counting from the 3.0.0-beta.1 would be better, but this is still ok
        fixture.AssertFullSemver("3.0.0-beta.2+22"); // 3.0.0-beta.2+2 would be better

        // we now want to get the changes from develop onto release/3.0.0 for the 2nd beta
        fixture.MergeNoFF("develop");
        fixture.AssertFullSemver("3.0.0-beta.2+23"); // Ok cool

        // ok, let's look at develop
        fixture.Checkout("develop");
        // eh, wait what? Why has the version jumped back from 3.1.0 to 2.1.0?!!
        fixture.AssertFullSemver("2.1.0-alpha.8");
        // eh, ok, an extra commit should fix that
        fixture.MakeACommit();
        // what?! Why do we reset back to alpha.1?! This will collide with a previous versions!!!
        fixture.AssertFullSemver("3.1.0-alpha.1"); // expecting 3.1.0-alpha.9
    }

Workaround

    [Test]
    public void WorkaroundThisBehaviorByUsingDifferentVersions()
    {
        using var fixture = new EmptyRepositoryFixture();
        fixture.MakeATaggedCommit("2.0.0");
        fixture.BranchTo("master");
        fixture.BranchTo("release/3.0.0");
        fixture.BranchTo("develop");
        fixture.Repository.MakeCommits(8); // on develop
        fixture.AssertFullSemver("3.1.0-alpha.8");

        // work on a beta release
        fixture.Checkout("release/3.0.0");
        fixture.Repository.MakeCommits(20);
        fixture.AssertFullSemver("3.0.0-beta.1+20");

        // finalize the 3.0.0 beta
        fixture.Checkout("develop");
        fixture.MergeNoFF("release/3.0.0");
        fixture.Repository.Branches.Remove("release/3.0.0");
        fixture.AssertFullSemver("3.1.0-alpha.29");

        // start the 3.0.1 beta
        fixture.BranchTo("release/3.0.1");
        fixture.Repository.MakeCommits(10);
        fixture.AssertFullSemver("3.0.1-beta.1+10");

        // finalize the 3.0.1 beta and release it
        fixture.Checkout("develop");
        fixture.MergeNoFF("release/3.0.1");
        fixture.Repository.Branches.Remove("release/3.0.1");
        fixture.AssertFullSemver("3.1.0-alpha.40");
        fixture.Checkout("master");
        fixture.MergeNoFF("develop");
        fixture.AssertFullSemver("3.0.1+12");
    }

Context

Creating a beta tag (e.g. 3.0.0-beta.1) is then only useful if the develop and the release branches are completely independent.

I'm not sure how we could implement a fix for this. Finding the base commit from which the metadata value is currently calculated using the vanilla MergeBase functionality of git, which finds the shortest intersection of 2 branches.

Any ideas?