ACE-408 and other related JIRAs.
We have limitations on the number of items that can be processed in a tree operation such as DELETE in a single transaction. i.e. you are always going to hit a limit of how many things you can delete/process/track in a single txn - and the more people/rules/processes using the system the more likely it gets that the large transaction will fail for some reason. You could quickly get to the point where you can only ever delete a small number of items transactionally at a time on a large well used system.
From a client perspective, we would like a non-transactional tree delete operation implemented. My reasoning is; this is exactly what filesystems and other hierarchical systems use when a tree operation is requested. Windows, Linux and Mac file-systems all perform non-transaction tree ops e.g. Delete, Move, Copy - you can cancel these midway, and there is no attempt to "roll back" and if a few things in the operation fail for some reason (e.g. concurrent modifications or similar) then they do the "best" they can on the rest and report back the failures. This is a much more usable system for large tree operations, in fact it is the only sane mechanism for this type of large operation.
This suggestion implies a few things though - it implies reporting of operation progress and probably it is an async operation that we can continually poll via an API for those updates. This would allow a user to kick off a big delete, and get notified of the progress in the UI and optionally cancel the remaining if they see fit. This is again what filesystems do.