One of the things I had on my wish list ever since I started using
rebase regularly: 'darcs rebase amend' should be exactly like amend
(including support for all the options that amend has), only that it
allows me to select any patch I want, suspending any other patch that
depends on it.

[I currently emulate this with 'rebase suspend -p patchname' (or -h
hash, or else hitting 'w' until the patch to amend comes, then hit 'y').
Afterwards I unsuspend it and can now amend it.]

Bonus points for automatically unsuspending the suspended patches
afterwards (but only those that were suspended by the rebase amend, not
any that were already suspended before we issued the command). This
should probably be enabled with an extra option. However, this extra
feature makes sense only if we stop at the first conflict when
unsuspending, see issue2552.

Another option for the UI would be to include this in regular 'amend', 
perhaps with a '--rebase' option.

Hm. When I proposed 'push --rebase' you convincingly argued that 'rebase
push' would be the more consistent choice. I agreed (and still do) and I
think the same arguments apply here.

Good point. Looking back, what I said then was

> I think we have discussed before moving from 'rebase pull/apply' to 
> 'pull/apply --rebase' and I'd be fine for that to happen. I'm not so 
> keen on a mixture.

I think amend is probably the top candidate for migrating to a --rebase option, because it's the 
smoothest transition in UI terms; indeed "deep amend-record" is initially how I thought about 
rebase. But we should at least have a plan for moving towards '--rebase' options everywhere before 
we introduce any.

Fine. So let's separate these two questions. We can open another issue
to discuss a possible move from 'rebase apply/push/pull/amend' to
'apply/push/pull/amend --rebase'.

Ganesh, you said
> indeed "deep amend-record" is initially how I thought about rebase

It occurred to me that another way to implement "deep amend" would be to
commute unrecorded changes backward until we hit the patch we want to
amend. If a commute fails, we merge i.e. force-commute, creating
conflicts on the way. Have you thought about that?

Apropos, I would really like to able to do force-commutes explicitly
with a command.

For those who are not so familiar with patch theory: the merge operation
takes two patches a:X->A and b:X->B with the same start context X and
creates two patches b':A->Y and a':B->Y that end in a common context Y
and each start where the other (unprimed version) ended. This always
"succeeds" since we have added Conflictors or Mergers to the set of
primitive patches just so that it does. Now, take another pair a:X->A,
b:A->Y of patches we want to commute. We merge a⁻¹:A->X with b:A->Y,
giving us a new context B with (a⁻¹)':Y->B and b':X->B. Then we can
define a'=((a⁻¹)')⁻¹:B->Y and thus (a,b) commutes to (b',a'), which is
what I mean with force-commute.