I agree mostly, but I would be wary of storing OTP codes and passwords together. You should choose to lock the OTP codes and passwords inside separate vaults with separate passwords.
The reason is that the OTP is a form of 2-factor auth, and hence should be kept separate from your main password. If passwords and OTP codes are stored together and an attacker gains access to this information, then the OTP codes are effectively moot.
I don’t like the idea of the login key opening anything in the Wallet, because I I walk away from my computer, forgetting to lock it, someone can dive in and access my passwords.
That is one of the things I dislike about the ‘wallet’ system on GNOME desktops. I always installed Kwallet on GNOME desktops, so I could have a separately secure Wallet.
But I lock always my PC if I left them (training due to a law in our company as HW privacy and security respnsible). Additional you can use your smartwatch or smartphone via BT, to lock the wallet.
If you have a HW token like a Nitrokey/Yubikey it is an good Idea to only temporary connect them. Also it is possible to use e.g. KDE Connect to be the enabler if no other HW token is available (so you need to enable the wallet via a realsecond factor!
The benefit will be that no other Desktop have in the moment a really full security concept integrated. Especially the combination from SmartPhone with KDE-Connect and a desktop app is very interesting, so no additional HW will be required!
There is sensible precedent for this. Windows uses their Credential Manager – accessible from control, since it’s a .cpl CLSID – for both Internet Explorer and Microsoft Edge (UWP and Chromium) in order to not duplicate the credential store.
For small projects such as Konqueror, Falkon, and Angelfish, having a single source of trust for credential storage is probably imperative to maintain security.
However, it might be even more important for KDE to implement something like Android’s