If you are limited to fast forward merging only one of your authors can merge. The second one needs to rebase and their updated MR will go through CI again, now on top of the first author's commit that has already been merged.
Ah I see what you mean. Yeah that is roughly equivalent to a manual merge queue. It's going to fall apart on medium/large teams because you'll constantly be rebasing and rerunning CI.
I think that is unique to Gitlab though. For example Azure DevOps will rebase the branch for you when completing a pull request.