Rubén Justo [off-list ref] writes:

quoted

When a sequencer is
driving a cherry-pick of master..topic1 and the user gets control
back in the middle, perhaps due to a conflict, should the user be
allowed to do "cherry-pick master..topic2", splicing these commits
from the other topic in the middle of the first cherry-pick session
the user started?

We already prevent this to happen.  Maybe because we do not want to
support multiple .git/CHERRY_PICK_HEAD files.  Anyway, to me, sounds
like a reasonable thing to have: that nesting limit of 1.  The same for
the other operations.

OK, as long as we prevent such kinds of questionable combinations
("two multi-commit cherry-picks" was merely an example---I did not
mean that is the only problematic case), I do not see much problem
with it.  In any case, teaching "status" how to show such a state
with less information loss, which is the theme of this patch, is not
making things worse---even if some of the states may be nonsense and
should be prevented, "git status" is not the place to do so anyway.

I didn't see if the proposed output from the command makes sense
(yet), but somebody else may already have done so and writing their
reviews on their findings.  Let's see if we get any positive reviews
and move it to 'next' after that.

Will queue in the meantime not to lose it in 'seen'.

Thanks.