Which means that the only way to do this effectively (and it really needs to be done) is to put a time-delayed transaction into the blockchain that can be recalled at any time before the trigger time - but only by whoever initiated the transaction; nobody else. So no - this is by no means an idea that has anything to do with chargebacks.
Why do you think the transaction has to go into the blockchain right away? Why is it no good to communicate it directly to the recipient and let their software put it into the blockchain when the time is up?
Secondly - it is extremely important that some way be devised to send a percentage of bitcoin in a wallet, rather than an amount. This will allow you to continue to use a wallet without worrying about having enough in it to cover a delayed transaction. It means there won't be any leftovers that will disappear forever. So if you have 1,000 bitcoin in your wallet and two kids to send bitcoin to in the event of your death, you send 50% to each - not 500 to each. That means that if you run across something you want to buy you just buy it - without having to constantly change your Dead Man's Switch transaction every time your wallet balance changes.
This doesn't seem to fit very well with putting everything into the blockchain from the start, because the blockchain doesn't know about wallets - it knows about the component parts that wallets manage, like key pairs and inputs and outputs. In practice if you want the amount that you leave to your heirs to be able to vary, you're going to need your client software to manage this for you by either making or amending new transactions when your balance changes. This also feels like a case where you'd be better off leaving it out of the blockchain and communicating the signed transactions to your heirs out-of-band, which should be possible even with the network as it is, IIUC.
Obviously we'd hope that you'd have client software to make all this stuff easy so that the user doesn't have to worry about broadcasting signed raw transactions and what-not, but we'd need that either way.
Why do you think the transaction has to go into the blockchain right away? Why is it no good to communicate it directly to the recipient and let their software put it into the blockchain when the time is up?
It has to go into the blockchain because if it doesn't you need lawyers and communication and a recipient technically savvy enough to put it into transaction format. I can think of any number of cases where a transaction just showing up in an heir's wallet is the best option - and several where it is the only acceptable option. For example:
While you're still alive you have your intended heirs install clean wallets, which are intended just for their inheritance. Say you have two kids... and also say you want to leave 20% of your bitcoin to one, and 80% to the other. What happens if someone brings a lawyer into that after you're dead and can't control your own money - or if you stipulate in a will that nobody can contest it, but they do...? Uh-huh. That'll work great. But with a Dead Man's Switch bitcoin inheritance, properly set up, nobody knows how much anybody else got. And no lawyers get a cut, either.
As for the percentage thing - you're right. The blockchain doesn't know about wallets. And maybe that's not as absolute a requirement as a transactional Dead Man's Switch. But it sure would be handy if it could be worked out. I'm sure the Martingale freaks would love it.