I was thinking a little bit about how to implement trash, and had a few ideas:

• Trash is just a special folder that watches (via queries) some well known attribute on items, such as "deleted" or "trashed" (I might prefer "trashed" because its more specific, wheras deleted could end up being an overloaded attribute)
• This attribute would probably need to be on ContentItem^? since that is a sort of user-level item that can be thrown out
• When an item is moved to the trash from a particular collection, it is probably removed from that collection via the collection's .delete() method, but it continues to exist in trash and possibly other collections
• When the trash is emptied, items that exist in both the trash and other places might need some warning from the user, to ask if they really want it deleted from all collections? (or maybe this would happen at the time the user clicked 'delete'?
• If the "removal from other collections" happens when the user clicks delete, then the trash (or the content item) might want to maintain a list of collections that the item USED to be in, so that if Undo happens, it can be re-added to all the old collections. This hinges on Undo requiring special behavior, rather than just going off of commit. (but I'm skeptical about tying Undo to Commit in the first place)