This turned out much longer than expected, sorry about that 
these are just my 2cts so feel free to just skip it
Wow, this is a great thread!
I love seeing everyone coming together and discussing features like this. I’m a little late to the party but I’ll share some thoughts (the first one being: this thread probably belongs in the Internet Identity category, which dfinitly deserves some love (pun intended)).
There are some points that were brought up in the original “II Lack of Security” post that I think we should keep in mind. The first one is that II was made to be as simple as possible to be flexible, but now it’s clear that it is too simple, because it lacks some important security features raised originally by @Roman . The second point was that “seed phrase” really is a misnommer in II land. A “seed” phrase really is some random (unique, immutable) material generated when initializing e.g. a wallet. In II land I think it’s more correct to call this a “recovery phrase”.
I really like the idea put forward by @lastmjs, and I LOVE that @dostro actually took the time to make mock-ups! What I understand from the original idea is this: If you have a recovery phrase, then you cannot remove said recovery phrase without proving you have the recovery phrase. dostro in your (very welcome) “sheparding” post you suggest we focus on agreeing (or not) on whether this should be opt-in or not (also brought up by lastmjs and others), and bring up bjoern 's worry about whether implementing a “simple” solution now and implementing a full solution later will be costly; I’ll share some thoughts on both (again, just my 2cts).
First, should this be opt-in? Whatever solution is agreed on here will probably need to be opt-in; at the very least we cannot just make all existing recovery phrases “secured” (i.e. you need the phrase to delete the phrase) because lots of people (probably myself included 
) never actually wrote down the phrase (and we can’t just have those people have their single recovery phrase slot be taken by a phrase they don’t remember). Basically we need to support (some) backwards compatibility (as also brought up by @skilesare and the Origyn (Orygin?) use case). Either way, looks like everybody agrees: solution should be opt-in.
Then, is it (too) expensive to implement a stopgap solution? Well, that largely depends on the stopgap solution, the “final” perfect solution, and the engineers who implement it. And while the Identity Labs are stellar, I can’t vouch for those @#* Internet Identity guys!!
More seriously, it’s very likely that whatever solution we come up with will effectively involve “changing the database schema”, i.e. changing the data we write to the canister stable memory. This means: an upgrade that can go wrong, potentially no rollback, and potentially shooting ourselves in the foot and regretting it for the next 5 years. So I think we can agree on a stopgap solution, but before we implement it we will need to have some idea of what the “final” solution will be, and some idea of how it will be implemented (basically do some thought experiments on what the future stable memory schema will look like and how we can migrate to it as we implement the “final” solution).
Now I’d like to share some thoughts on other aspects of the proposed solution. What I gathered from your posts lastmjs and dostro , and I may very well be wrong, is that you are only talking about recovery phrases, and not recovery devices. There are some very good points (I think by @coteclaude and @vavram, and empirical evidence shared by bjoern) that plaintext phrases can be lost and corrupted. But more importantly in my opinion (which appears to be shared by @Desinternauta, @GLdev and bjoern) is that the phrase keeps transiting through the browser and the monitor (on generation and then on input), which makes it subject to theft.
(quick side note: wpd suggested we force the user to input their recovery phrase when deleting any device, not just recovery devices; that’s something I thought about as well when reading the thread, but it would mean getting the “secured” recovery phrase in and out of the safe repeatedly, and typing it in the browser, which will be a real hassle and a risk; so I suggest we don’t do that)
With all that in mind, I think it’s worth thinking about making the recovery devices “secured”. bjoern also gives a nice example of how e.g. a recovery phrase can be used on a Ledger device; in this case the user still has a recovery device from II’s point of view, but can use an actual seed phrase which is only used on the Ledger device, and not in the browser. My recommendation would then be to only make the recovery devices “secured”, and not the recovery phrases. I’m sure some people will disagree though, in particular dostro and lastmjs since they explicitly suggest making the recovery phrase secured (and not the device); I’d love to hear examples of workflows and situations where the FIDO device/hardware wallet is not suitable.
Now there are also some great ideas (by @kusiyo and @justmythoughts for instance) that are more complicated (multiple devices, social recovery, etc) and that we should keep in mind for the future (or as I believe dostro puts it: “backlog out-of-scope questions, ideas, and discussions”).
Ok I didn’t expect this post to be so long and my wrist is starting to hurt so I’ll wrap up, but there’s one more thing I’d like to bring up, and that’s the question of “who will implement this”. This is really exciting to me because this is the first feature that’s really driven by the community. I think as many people as possible should share their (structured) ideas here and in the community chat tomorrow (can someone share the link?). For implementation however, I think DFINITY’s policy (at least for NNS and II) has been that external contributions are not accepted. I think this makes a lot of sense, because so far virtually no one has submitted patches as far as I know, and because a malicious contribution in either II or NNS (dapp) would be catastrophic for the whole ecosystem.
But then, I don’t believe this to be a “hard and fast” rule/policy. I would be uncomfortable knowing that a feature as sensitive as the one suggested here is the first to be contributed externally to a DFINITY team that hasn’t had a chance to sharpen their anti-byzantine review skills, but it would be a great opportunity to loop the community in. After we’ve decided on what exactly the solution will be here, the team could for instance deploy a test version of II that everyone can play with and then feedback can be shared here. Basically, while DFINITY will probably be writing the actual code, it would be awesome if everyone could still be working on this.
(note, these are just my own 2cts)
(P.S.: Actually a great first external contribution would be a patch that replaces all the occurrences of “seed phrase” with “recovery phrase”)