For example, take a patch with a traditional darcs hash of 
'20080513112149-05dcb-4c273a98eae16cc9d273f18af9907f9f2e567224' 
and a new hashed file name of 
'0000012256-2f91882e2149f43e2463fb9ee80edd67e379734ab0e395ae6cf36655a595bff0'.

The command "darcs2 changes --match 'hash ...'" should be smart enough to match
either hash type. Currently it only matches the old hash.

Tested on darcs 2.0.0 build Apr  9 2008, at 17:14:20, stable release binary for
MacOS X.

Do the new hashed file names correspond to files or patches? 

I'm personally OK with rejecting this request as 'wont-fix'. Exposing one hash
to match in the UI is enough for me. If a second hash really expresses the same
thing different, it could just be confusing document and interact with. 

I'm going to go ahead and mark this request 'wont-fix' now, but someone else may
re-open it if they disagree.

The hashed filenames correspond to file contents. Same patch can (and will) carry
different "new-style" hashes depending on how it is commuted. You don't want to
refer to a patch through the hashed filename. The original "old-style" (but
that's really just misnomer, it's a "patch hash" vs "file hash") hash refers to
the patch uniquely and that's what you want to stick to. I agree with wont-fix.

Should this become an FAQ of some sort?  Like it or not, people do look in
_darcs/patches :-) (or they create tools that grab patches).  

As an aside, maybe it would be useful if darcs provided a utility to return the
hashed file name corresponding to a given patch.

I believe adding the filename holding the patch to changes --xml output might not
be hard. *However*: this file is not guaranteed to exist in a local repository
(lazy repos won't have all of the patch files). Dunno about usefulness of such a
feature.