Thanks everyone for the comments. It's great to receive such high quality feedback so promptly! It's easier for me to post responses one at a time. Here goes.
Though it's arguably more fragile in one sense that you may think you can release a private key securely but really you cannot because if you leak too much you are broken. It's difficult to write software which will only act a small non-zero number of times e.g. it crashes and forgets that it's already performed one disclosure, certainly the user cannot be counted on to remember such things. So I think it would be an obvious improvement and might well be worth an increase in the resulting master public key size just for additional robustness, I don't know that in practise it would safely permit intentional use of it.
I certainly agree that
- You would need to be very careful applying this scheme for the purpose of fault tolerance.
- The wallet's utility is limited by the fact that you need to commit at the wallet's inception to a maximum amount of leak you're willing to tolerate over the life of the wallet.
But at the very least, you could protect against a one-off, black-swan event that leaks only a fixed number of keys. It forces an attacker to compromise a bunch of keys---not just one.
Don't forget that there could be other uses of this wallet aside from fault tolerance (which admittedly isn't a killer app). The treasurer-auditor is one, but I couldn't think of any others.
I'll reply to the second part of your comment later. Cheers.