In your scenario though the bad news is not BitPay needs to figure out a way to return your coins. You can't undo it and eventually it will confirm (unless a duplicate of the prior output is what confirms). So you are now out the donut and coins.
Oh yes of course, stupid of me, the customer loses out there. But it still always comes back to the same thing for me: wallets should not attempt to spend unconfirmed change. Yes, I know there are some practical difficulties there with the way wallets are designed, but it doesn't look insurmountable - at worst it just causes a few inconveniences.
Do you realize how confusing and frustrating can be for users to disallow spending of unconfirmed change?
Imagine you received 100 BTC and you spend 1 BTC - suddenly 99 BTC become unspendable for 5,10, 30 minutes... That's very counter intuitive and will confuse a lot many users who do not understand how the protocol works.
Not allowing to spend unconfirmed change is an important steps backwards, and I think that we shouldn't downplay it's effect. I'd probably have it as an optional feature on the client, but if possible I wouldn't make it the default behaviour.
About 0-conf: for small, day by day payments they were absolutely safe. The cost to perform a double spend was simply not worth the cost of a coffee. Now, that changes, 0-conf are not safe even if the buyer is 100% honest and the cost of the product is negligible: again we cannot downplay the effect of that, it's quite serious.
Yes, I do appreciate the problem. But I would say it could/should be attacked from three angles: 1, disallow it by default but allow it to be switched on, 2, make people aware that they sometimes have to wait for confirmations before proceeding and 3, some alterations within wallets, e.g. automatic internal transfers to split up into denominations.
For sure, it is much more convenient if we don't have to worry about this - but if I'm reading things correctly, malleability is with us for some time.
Zero conf payments still work - it's just zero conf payments spending existing zero confirm payments that don't.