I have stumbled over this inconsistency every now and then.

The following remark does not explain the difference in behavior for this
particular problem, it merely provides context.

File path arguments and --matches "touch <file path>" are implemented in a
completely different way and can have different effects. The former is more
powerful and more useful because it accumulates the effect of 'move' changes
during traversal of the patches (going backwards from the head). A "touch
<file path>" matcher only looks at the patch itself without considering the
history.

It would be nice if we could somehow fix "touch" matchers to have the same
semantics as file path arguments. One idea would be to use the patch index,
which does keep track of 'move' changes i.e. file identities. This would be
a challenging refactor that could permeate all of the patch matching and
patch selection code. The upside is that it would get us rid of the ugly and
unprincipled code that currently implements file path argument matching.

1 patch for repository https://darcs.net/screened:

patch c6c78d6402188570489f139342f3d352d2bab871
Author: Ben Franksen <ben.franksen@online.de>
Date:   Sun Jun 23 09:57:09 CEST 2024
  * accept issue1241: rollback with file beyond tag

Attachments

• accept-issue1241_-rollback-with-file-beyond-tag.dpatch
• patch-preview.txt

Looks fine