Tao Klerks [off-list ref] writes:

At first I hoped that "git switch" might have fixed this - and in a
limited sense it has, in that instead of *silently discarding* the
merge state/metadata, it refuses with "fatal: cannot switch branch
while merging".

I think this is in generally seen as a vast improvement over the
"silently discarding" to have the safety valve.

I'd like to understand whether this behavior, the fact that you can't
easily/straightforwardly/intuitively complete a merge onto a new
branch (with the exact same "first parent" commit of course), is
intentional for some reason that I am failing to grasp, or just a
missing feature.

It makes complete sense, of course, that switching to a *different
commit* than the one you were on when you started the merge, should be
illegal... but why would switching to the *same* commit be either
illegal (git switch behavior) or destructive (git checkout behavior),
as opposed to just letting you get on with it, as it does with other
in-progress local working tree states?

I think this is mostly that nobody spent enough brain cycles to
ponder on things like:

 - Is it always safe to switch from a merge in progress to a newly
   created branch that point at the same commit as HEAD?  Why?  Is
   the story the same if the switched-to branch is an existing one
   that happens to point at the same commit as HEAD?

 - Maybe the answer to the above question is not "it is not quite
   safe to switch during a conflicted merge, but by adjusting X and
   Y while switching to a new branch, we could make it safe".
 
 - Even if the answer to the question above is "yes it is always
   safe", if it is not safe for a similar situation that ends up in
   unmerged index (i.e. the index with any path at non-0 stage), the
   way we determine if we are in "a merge in progress" situation
   must be reliable.  Is it?

 - Conversely, perhaps it is also safe to switch to a different
   branch that points at the same commit as HEAD from the conflicted
   state after some (but not necessarily all) of the following
   operations: "am -3", "cherry-pick" (single commit), "revert"
   (single commit), etc.  Can we come up with a reliable way to
   determine if we are in such a situation?

 - These "other mergy operations" that can leave unmerged index may
   share the same "is not safe out of the box, but can be made safe
   by adjusting some stuff".

After that is done, we could update the codepath in "git switch"
that says "ah, your index is unmerged, so I will not let you switch"
to instead say "your index is unmerged; let's first see if you are
switching to the same commit as HEAD and then the way your index is
unmerged was caused by an operation that we decided is safe to
switch out of.  It seems to be one of the situations that could be
made safe, so let's do adjustment X and Y and let you switch".

And the reason why "git switch" punts is because nobody bothered to,
not because there fundamentally is some reason why it shouldn't work.