[BUG?] 'git rebase --abort' couldn't abort aborted rebase

That's a good subject, isn't it? :)

So, to clarify: apparently it is possible to abort an ongoing 'git rebase' process with ctrl-C in just the right moment that a subsequent 'git rebase --abort' will refuse to clear it up.

I somehow messed up the upstream and branch parameters of 'git rebase', and ended up trying to rebase a fairly recent (post v2.24.0) branch on top of v2.22.0. Upon seeing the unexpectedly large number of patches I realized that something is wrong, hit ctrl-C right away, and this is what happened:

  $ git rebase v2.22.0 <a-branch-on-top-of-2.24.0>
  First, rewinding head to replay your work on top of it...
  Generating patches: 100% (1108/1108), done.
  Applying: send-email: move the read_config() function above getopts
  Applying: send-email: rename the @bcclist variable for consistency
  Applying: send-email: do defaults -> config -> getopt in that order
  Using index info to reconstruct a base tree...
  M       git-send-email.perl
  M       t/t9001-send-email.sh
  Falling back to patching base and 3-way merge...
  Auto-merging t/t9001-send-email.sh
  Auto-merging git-send-email.perl
  ^C
  ((5f07da12ac...) *|REBASE 3/1108)$ git rebase --abort 
  error: could not read '/home/szeder/src/git/.git/worktrees/WT/rebase-apply/head-name': No such file or directory
   
"Fortunately" it was in a separate worktree, so I could easily get out
of the situation by forcibly deleting that worktree.  Unfortunately,
that was exactly what I did, instead of securing the failed state for
later analysis...  sorry.
The only thing I still have is the list of files in the rebase directory,
rescued from the terminal's scrollback buffer:

  $ ls ~/src/git/.git/worktrees/WT/rebase-apply/
  < ... omitting the 1k+ patch files ... >
  abort-safety
  apply-opt
  author-script
  final-commit
  keep
  last
  messageid
  next
  original-commit
  patch
  patch-merge-index
  quiet
  rebasing
  rewritten
  scissors
  sign
  threeway
  utf8

All this is with a git built from current 'next', with a bunch of unrelated (none of them touches rebase or the sequencer) patches on top.