There appears to be a difference in how child record deletions behave when they're deleted manually as opposed to when they're deleted by a trigger or a flow. My particular use case has a parent object with one or more children in a required lookup from the child to the parent. Since the field requires a value, you can't delete the parent until the children are deleted.
When I delete the child record(s) manually they're sent to the Recycle Bin as expected. But a before delete trigger on the parent that deletes the child/children to remove the dependency (or a flow that does the same thing for users with a lower privilege level) nukes the child record(s) out of existence with no way to recover them.
I don't expect this to present a huge problem, but I haven't found any documentation or search results in the Salesforce diaspora that explain this difference in behavior.
My best guess is that when you delete the record manually, it's using Database.delete rather than a DML delete operation, but why that would make a difference is a mystery to me. Especially since the parent record is soft deleted -- by the flow.
Found the answer while looking for something else.
https://help.salesforce.com/s/articleView?id=000384460&type=1
Under Related Information at the bottom of the page, we find:
1. If a child record (like a Contact or Opportunity) is deleted and the parent record is subsequently deleted (Like the Account), the child record is permanently deleted. Even if the parent record is undeleted, the child record cannot be recovered, but if the child record is undeleted first this won’t happen.
Because of the relationship between the parent and child in my use case, the child record must be deleted first, and it is not possible to undelete the child first for the same reason. So this is expected (if inconvenient) behavior, and in this context unavoidable as well.
