I was just making sure that the record is clarified on existing memory vulnerabilities in Bitwarden: the client process memory is always purged of all sensitive data on locking of the vault (or logging out), except that in the Firefox browser extension, the memory cleanup can be delayed, unless the browser itself is closed.
As far as your feature request, it appears to me that you are essentially proposing a “semi-locked” state as a fourth vault state (in addition to logged out, locked, and unlocked). Some users might be unhappy about the complete loss of search functionality for Notes and custom fields, though…
Bitwarden is in the process of going this route, as well. However, the individual encryption keys for each vault entry must still be available in memory for decryption to work, so this will not protect against an attack that exfiltrates a memory dump.
My understanding is that the fact that Bitwarden’s code base is primarily TypeScript and C# presents technical hurdles to leveraging some of the memory hardening techniques deployed by KeePassXC (which is written in C++). Past Github discussions (including the ones linked above) have revealed that browser extension processes in particular have little to no control over the timing of garbage collection (thus, “immediate memory clearing after use” may not be possible to implement).