I like the promise of destructiveChanges.xml (you can finally remove object fields, triggers, etc. as part of your build) but it is unusable for our org.  Including this file renders the build not re-runnable...in other words, it breaks the build after one run in the same environment!

If you run it once, great, the elements are deleted.  But if you run it a second time you get errors similar to these:

BUILD FAILED

build.xml:62: Failures:

objects/Contract.object(Contract.SetContractToExpired):In field: name - no WebLink named Contract.SetContractToExpired found

objects/Contract.object(Contract.SetContractToCanceled):In field: name - no WebLink named Contract.SetContractToCanceled found

objects/Contract.object(Contract.SetContractToPaused):In field: name - no WebLink named Contract.SetContractToPaused found

The build fails when these elements are not found.  But they are not found because they were deleted in a prior run!   The build should not fail if elements to be deleted are not found.  It should either issue warnings or completely ignore, but it definitely should not fail.

If this file is included in source control, you will have problems using a continuous integration tool like hudson or cruisecontrol.  You will have problems running the build twice in the same environment.  You will have problems maintaining the file across a team of developers, some of whom have built using the latest destructiveChagnes.xml and some who haven't.  

As I'm writing this I realize I should post this on the Ideas board, but I'll post here in case someone has figured out a workaround for this and would like to share.

In the meantime we are going to continue to delete elements manually through the UI of every sandbox and production environment, ugh.