Avoid re-resolving conflicts in a git rebase including merge commits

Trying to move history from one repo to another (no common root) by adding the source remote and rebasing to a branch on the local destination repo.

Source:

A-B-C
 \ /
  E

Wanted on destination:

F-A'-B'-C'
   \   /
     E'

Documentation for git rebase --rebase-merges says it will preserve topology and re-create merge commits, but:

Any resolved merge conflicts or manual amendments in these merge commits will have to be resolved/re-applied manually.

Now, I want to avoid re-resolving conflicts and I am puzzled why this is needed at all. The content of the merge commit is there, I can detach HEAD to to.

So, I tried

$ git rebase -i --onto destnewbranch --root --rebase-merges srcbranch
Could not apply C... master # Merge branch 'master'

(detached HEAD|REBASE x/y)
$ git status
interactive rebase in progress; onto F
Last commands done (n commands done):
   pick B
   merge -C C master # Merge branch 'master' 

You have unmerged paths.
  (fix conflicts and run "git commit")
  (use "git merge --abort" to abort the merge)

To solve conflicts, I am taking the content of C:

$ git reset --hard C

Now content is good but history is not, so:

$ git reset --soft HEAD@{1}

All is there is left to do is to move on with the rebase:

$ git commit
$ git rebase --continue

However, history is wrong since I am left with:

F-A'-B'-C'

So C' is not a merge commit, although it has the resolved changes of both B and E. Merge commits that don't cause conflict are successfully rebased with the topology intact.

I think it is me who is messing up the the MERGING state of the rebase by resetting and the final git commit will NOT create a merge commit, but a regular one. If I don't do the resets and resolve the conflicts manually, git commit will create a merge commit.

git version 2.26.0.windows.1