Let me give you an example of why what you want - makes no sense:
I’m recording a 3 piece band - guitar, bass, drums… I ask the band if they’re ready, they say “yes”, I say “rolling”, hit record, band starts the song together but whops, the bass players volume knob was down, band stops playing after a second knowing it’s a false start.
You’re telling me, if I delete that take… it shouldn’t go straight to trash…? If your idea was implemented, I would have to go into the pool to find all these junk takes and manually drag them to trash?
Particularly annoying because deleted takes get put in the trash automatically without my authorisation >
You’re giving your authorization when you press the delete key.
This is just how the program works, and it’s actually fairly logical once you understand it. You’re not using the program right, you’re not utilizing the multiple utilities or topologies to preserve “maybe needed” takes, and so your work ethic has an issue here. The protocol of deleting newly recorded files is designed to get rid of blatantly unneeded things and then purging them, to keep the project organized and reduce it’s size which saves a lot of back up time. Files stay in the trash in case of the occasional mistake between the deletion and the purge in which maybe a user has lost their undo history.
You simply should not be using the trash the way you are, which is probably why it is limited in function - - - so that users don’t erroneously depend on it like you are. I’m trying to help you, engineer to engineer so please accept this as if we are building a bridge in which peoples lives are at risk, and you’ve overlooked something in your design, there shouldn’t be this kind of resistance to critical counter input.