Bug: Wrong prerelease version

The following construct results in a wrong prerelease version and thus a failing job, as the tag already exists.
Steps to reproduce:

1. master tagged v1.0.0, fast forwarded from develop
2. commit feature on develop-> Commit is tagged v1.1.0-develop.1
3. create branch release/test-release from develop -> Same commit is tagged v1.1.0-rc.1
4. commit feature on develop -> fatal: tag 'v1.1.0-develop.1' already exists

Expected Behavior: Tag v1.1.0-develop.2 instead of v1.1.0-develop.1

The previous prerelease version does not seem to be recognized, although it was tagged. Maybe this is caused by the commit being tagged twice? This case should be accounted for. Or am I doing something wrong?

Error log Context:

[semantic-release] › ℹ  Found git tag v1.0.0 associated with version 1.0.0 on branch develop
[semantic-release] › ℹ  Found 2 commits since last release
[semantic-release] › ℹ  Start step "analyzeCommits" of plugin "@semantic-release/commit-analyzer"
[semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: feat: conflicting feature
[semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is minor
[semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analyzing commit: feat: add gitignore
[semantic-release] [@semantic-release/commit-analyzer] › ℹ  The release type for the commit is minor
[semantic-release] [@semantic-release/commit-analyzer] › ℹ  Analysis of 2 commits complete: minor release

.releaserc.json

{
    "branches": [
        {"name": "master"},
        {"name": "develop", "prerelease": "develop"},
        {"name": "release/*", "prerelease": "rc"}
    ], 
    "plugins": [
        ["@semantic-release/commit-analyzer", {
            "preset": "angular"
        }],
        "@semantic-release/release-notes-generator",
        ["@semantic-release/exec", {
            "publishCmd": "echo ${nextRelease.version} > .version"
        }],
        "@semantic-release/gitlab"
    ]
}

Start by reproducing the branch and tagging sequence from the issue with the provided .releaserc.json, then inspect the release log around prerelease version detection. Done means the second develop release uses v1.1.0-develop.2 instead of attempting the existing v1.1.0-develop.1 tag.