So, what we need is a way to remove that doubt from the transaction.
Not really. Merchants accept some risk of chargebacks from employing credit and debit card payment processing networks. They monitor it and weigh the cost/benefit.
Here's why they will accept some risk. Selling a Mc SubKing presumably provides profit.
A race attack is not easy to perform (when the merchant is properly configured -- no incoming connections, and outgoing explicitly to well connected nodes and/or subscription to double-spend monitoring service). And there are no guarantees that the attacker will succeed.
So if I as an attacker some how were to get success 5% of the time, that means I pay for and eat 19 Mc SubKings to get the 20th "free" (on average).
I bet the restaurant would take that customer's business any day of the week, even with those odds. Fraud is illegal so the attacker would probably be easy to identify -- as the only one ordering a Mc SubKing wearing a full facemask.
If the attacker attempts the Finney attack, success is more likely but it is very expensive. In that attack, the payment is only made after a block (containing the double spend transaction) has already been mined but is held from being broadcast. It costs the attacker about $2 per second (at BTC/USD of $50) to perform this attack. This attacker would be easy to identify also. He's the one waiting at the counter for hours until his miner gets a block -- then screams frantically about getting a few Mc SubKings ordered, fast, and sends payment as soon as the QR code is presented. As soon as the merchant accepts payment the mined block is released and the funds double spent. The restaurant can know of this right away, so again, the attacker would never order anything that can't be hauled out to the getaway car in a matter seconds. So the full facemask would probably be helpful there as well.
I think for example BitPay already does this optionally. It does not wait for confirmations for small amounts for some merchants. This is not a problem.
It does however expose the merchant to the same risk of a double spend attack that the OP is suggesting is the reason to wait for confirmations -- BitPay doesn't insure or protect against it happening, they simply notify the merchant (via the same channel as the original payment notification is sent).
Now there is a scenario where a merchant would not want to accept on 0/unconfirmed.
A coin change machine at an unattended laundromat. The attacker could try over and over to get a successful race attack. For the unsuccesful attempts, the atacker gets quarters at face value. Essentially if the items is high value purchase (above $100), or low margin, and can be purchased without revealing identity -- that's not a good candidate for 0/unconfirmed.
There's other solutions that could be used as well ... green addresses, BTC payments through an Open Transactions server, Ripple, redeemable codes, and much more. The problem that Square just had with their gift e-codes shows that regulations make it expensive to pass around digital credits (as money transmitter licensing and consumer protection regulations would need to be considered). So Bitcoin may have an opportunity to go where others can't.
