Makes sense. I was afraid that would be the sort of order it worked in, but I had to ask.
Thank you for taking the time to respond 
I did have some other ideas to make TOTP work better, with the added bonus of them also having positive effects on other things.
-
Add an option in the right click context menu (ie: ‘Find Matching Logins’, ‘Add Element ID to Form Whitelist’, ‘Generate Password’) that adds that input’s ID to the whitelist (I’ve seen something similar suggested somewhere already but can’t remember where)
-
Backup/restore of serialised settings via file or cloud (Google Drive, etc), like the Reddit Enhancement Suite, so the whitelist (and the other settings) can be added once and then synced easily/automatically.
-
Still hook into the KPDB to derive ID’s for the alternate whitelist concept from above, but only as a one-off on connection to the db, or as a button/menu entry somewhere (or both).
I can think of two ways this might work.
The first is by defining a special entry in the db whose sole purpose is to serve as a host for the various settings being persisted (could include more than just whitelist), and then either manually specifying it in Kee, or having a default setting with a fairly unique naming convention to reference it automatically.
The second is to apply the ‘Only run on connect or when manually triggered by the user’ thinking to my original suggestion. Scan the whole DB for user-specified Form fields, and just soft-persist them for the normal checking process alongside the properly configured whitelist.