Or you can use the strengths of cryptocurrency and split a key between a safe deposit box, your home, and yourself, and require 2 of 3 of them to get the original key.

That definitely helps against many scenarios, but "home and yourself" means you're still in immediate control of funds while you're at home, so you're still vulnerable to armed robbery. You want to make it so your answer to the robber is "I can't, the bank's not open."

And then what? The robber who went through the trouble of breaking in and demanding your money will apologize and see himself out?

If you had a large number of gold coins, would you keep them at home to avoid annoying robbers?

Then make it 3 of 3, it all depends on your threat model.

For me, my biggest threat is loss, followed by theft, so it makes sense to have some redundancy even if it means reducing the security against theft.

That's a neat idea. Do you mind expanding on it?

Shamir's Secret Sharing allows this even without dealing with multisig wallets.

I like the idea but I wish there were a widely-trusted implementation with public security reviews, maybe built into wallet software.

It's not a terribly large amount of code, and it's easy to test, even with a "live" key (since testing that any n of m can be recombined doesn't force a spend or reveal anything externally).

Also, it's a fairly well-known system, so I don't see it being collectively "forgotten" on the timescale of a few decades (it's been around since the late 70's i believe).

I'd love to get it integrated into wallet software, as it's such a safe and reliable way of storing secrets that lets you be as "secure" or as "reliable" as you want with just a slider.

This is what I had in mind. And it can scale to any "n of m" you want, without any if the downsides if multisig wallets (namely larger transactions, and more complex Bitcoin wallets required)

2 of 2, 3 of 5, 7 of 10, etc...

it's called 2 of 3 multisig and it's a standardized part of most cryotocurrency. it requires X of Y separate key signings to complete a transaction from an address

You could take a private key and split it into three parts and store them separately.

You should rather xor it with two other random keys.

I don't think I follow you, could you please explain what you mean a bit further?

You don’t really want to split the key (as in if the key is n bytes, split it in 3 segments of n/3 bytes) because if one has two segments, I imagine it’s not inconceivable to infer the third segment from the public key and the other two (though I haven’t made the math).

Rather you have a private key p of n bytes. Create two cryptographically random keys k1 and k2 of n bytes each. Derive a key k3=(p XOR k1) XOR k2. k1, k2 and k3 are your distributed keys. To recompute p you need to do p = (k3 XOR k2) XOR k1.

A XOR is trivial to implement and I would expect be reasonably robust.

splitting the key into multiple segments reduces the number of bits one has to guess.