Multiple seeds can be used, for example:
1. Seed #0, which is an internal seed that is not disclosed or stored. This must be brute forced when re-generating the private key, so it is quite weak. It is intended as some extra protection against an attack.
2. Seed #1 (stored in one location) which takes ~1 day to brute force if lost.
3. Seed #2 (stored in another location) which takes ~1 day to brute force if lost.
If the user has the passphrase, seed #1, and seed #2, all it takes is (say) 60 seconds to brute force the internal seed, and generate the correct privkey.
If the user loses either of the seeds, it takes 60 seconds + 1 day.
If the user loses both seeds, it takes 60 seconds + 1 day + 1 day.
Was thinking about this again today, and I've found a flaw in the above. I believe the total effort required to cover the search space is actually the
product of the effort per seed, rather than the
sum. This is because there's no way to know if you've correctly found a match for a single seed. The complete passphrase+seed+seed+seed combination is either matched, or not matched; there's no way to match a part of it.
In other words, if you lose both seeds, it will take 60 x 86400 x 86400 seconds (5,184,000 days) to brute force all possibilities, not 60 + 86400 + 86400 (2 days and 60 seconds).
To be able to independently crack a lost seed would require additional external validation, such as a hash of each seed stored in the blockchain.
Just wanted to update the above idea to point out that multiple seeds won't work as expected. A single seed would still work, since there's only one unknown part to force if it is lost.