When exactly should REBASE_HEAD exist?

As far as I can tell, REBASE_HEAD always points to the last commit that was attempted to be applied in a rebase, not matter whether that attempt was successful or not. In other words, when you break in a rebase with "edit" or "break", REBASE_HEAD is the same as HEAD (except when you break before the first commit, in that case REBASE_HEAD is unset).

I wonder whether it would make sense to set REBASE_HEAD only when applying a patch failed. That seems to be the main use case of it.

The reason why I am asking this is: I'm using lazygit, which, during interactive rebases, shows a combined view of the real commits that were already applied, and the remaining commits that are yet to be applied (it gets these by parsing rebase-merge/git-rebase-todo); something like this, when I set the 2nd commit to "edit":

  pick   4th commit
  pick   3rd commit
         2nd commit  <-- YOU ARE HERE
         1st commit

This is great, but assuming that the 2nd commit conflicted, currently the display looks like this:

  pick   4th commit
  pick   3rd commit
         1st commit  <-- YOU ARE HERE

I would like to extend this to also show a "fake entry" for the commit that conflicted, if there is one. REBASE_HEAD is perfect for this, except that I need a way to distinguish whether it was applied already or not.

I currently do that by comparing it against HEAD, and only showing it when they are different. That doesn't always work though, e.g. when I amend the current "edit" commit.

Any better suggestions how to work around this?

-Stefan