Some operations like obliterate and unrecord limit selection of patches to 
those after (and including) the latest clean tag. This is problematic for 
several reasons. On is that the concept of a "clean tag" depends on patch 
order. There is no way for users to observe whether a tag is clean or not in 
the current patch order. That makes it hard to predict which patches will be 
considered. Yet another problem is that regardless of whether a tag is clean 
or not, users may want to consider patches that a tag depends on as "frozen" 
-- which in fact they are, unless you unrecord or obliterate the tag first.

I propose that we change the condition to one that does not depend on patch 
order. More precisely, obliterate and unrecord (and perhaps others) should by 
default limit selection to patches that are not depended on by /any/ tag.

If the latest tag is clean (which it usually is) then this is exactly the 
same as before.

A slight correction wrt the actual behavior.

If the user specifies a matching option that counts as a "fist matcher"
i.e. one of the --from-xxx or --index=N-M variants (or the singular
match options but they are not supported for these commands), then the
restriction to patches after the last clean tag is not in effect. Same
if --not-in-remote is in effect; in which case the --from-xxx or
--index=N-M are ignored, but plural versions of "nonrange" match flags
(--patches or --matches) do take effect; because these are (also)
"nonrange matchers" and these are handled by the patch selection code.

See Darcs.UI.Commands.Util.preselectPatches for details, as well as
Darcs.Patch.Match.{firstMatch,nonrangeMatch}.

Any work on this ticket should include a cleanup of this mess.