to do a SUCCESSFUL double spend requires alot of speed and hardware. but to send out 2 transactions to 2 different addresses using 2 clients but only using one private key supply does not require expensive equipment. A successful double spend requires a confirm on both sides. meaning the 10 minute wait. but sending out 2 transactions that don't require waiting the 10 minutes is piss easy.
accepting unconfirmed transactions should only be allowed on products with delayed delivery. such as bitpay which can inform merchants that the payment has failed in 10 minutes and the merchant still has time to email the customer to attempt the payment again before losing their next-day delivery slot.
it is never EVER acceptable for instant access content.
examples.
if i sent
0.1BTC from 1HomeMachineAddress to 1VendMachineAddress
0.1BTC from 1HomeMachineAddress to 1VendMachineAddress
one of those transactions would instantly be ignored as it would appear as just an echo of the other, where many nodes pass around the same transaction (to avoid repeats)
but if i sent
0.1BTC from 1HomeMachineAddress to 1HomeMachineAddress
0.1BTC from 1HomeMachineAddress to 1VendMachineAddress
it would appear as 2 different transactions and would require a confirm to sort out the mess (10 minute wait)
Right but you are assuming that the receiver is not checking the balance on the address and that the user has spent in excess of the balance. That is not hard to do...
If my address has 1 btc and I have 2 tx for 1 btc each... the receiver can tell me to wait 10 minutes.... honest actors are not going to do double spends...
I still think an outright rejection for addresses with unconfirmed transactions is the most pragmatic way to go, buyers should be warned with notice that refund cannot be processed immediately.