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.