MR suggestions always get applied to branch tip

Dear GitLab gurus. We observed the following behavior just recently. I have tested this separately in a private repo as well. Can anyone confirm this? Is this a known issue? Is there a solution? Thanks!

Say you have created a branch feature-wip and a MR into master. When you, being on the GitLab diff discussion page of the MR

• edit a file in that branch interactively
• apply a code suggestion

then a commit will be created in feature-wip, with a commit message such as

    Apply suggestion to <filename>

The problem: the commit will always be made on top of the branch's tip, i.e. the most recent commit, and not the commit at which the diff discussion started. This is no problem, unless someone (or you) pushes new commits to feature-wip, moving tip forward. Now all not yet applied code suggestions refer to an older version of the file, but will be applied onto the new tip, which may lead to merge conflicts.

In the particular case above, we even saw a GitLab message saying something like "this ... referes to an older version of this file ...", with links to the versions and everything.

To make things more visual, this is what happens:

    * aab4893  (HEAD -> feature-wip, origin/feature-wip)  Apply suggestion to foo (GitLab GUI)
    |
    * b02d02f  Pushed
    |
    * 3edc93f  Apply suggestion to foo (GitLab GUI)
    |
    * f9c2a59  Apply suggestion to foo (GitLab GUI)
    |
    * 034b71f  WIP: foo
    |
    ...
    |
    * 7192849 initial commit

In this situation, GitLab could instead create new branch by applying onto the old tip 3edc93f

    * b02d02f  (origin/feature-wip, feature-wip)  Pushed
    |
    | * bec979c  (HEAD -> gitlab-automatic-branch-xzy2342)  Apply suggestion to foo (GitLab GUI)
    |/
    |
    * 3edc93f  Apply suggestion to foo (GitLab GUI)
    |
    * f9c2a59  Apply suggestion to foo (GitLab GUI)
    |
    * 034b71f  WIP: foo
    |
    ...
    |
    * 7192849 initial commit

Then we could use normal git to merge those, or GitLab could automatically merge and only create a branch when it cannot merge without conflict.

So: we have a file-locking-like situation here. Until all the MR's discussion items are resolved, nobody can (should not) commit to that branch. Bummer.