The original post is well written. There's another problem with the fix, though. If you can't spend unconfirmed change arising from confirmed inputs, once you've spent some money, you sometimes can't spend again until a few confirmations have been processed. There's now an option in the official QT client to enforce that rule.
This creates operational problems for Bitcoin use. Once you've spent some Bitcoins, you may not be able to spend any more Bitcoins for tens of minutes. Whether or not you can spend depends on the denominations of Bitcoins currently in your wallet. You don't have an "account balance", you have a collection of Bitcoin items with varying denominations, and this now matters. Explaining this to end users is going to be a problem, especially since the current user interface doesn't expose that level of detail to the user. With the "no spending unconfirmed change" rule enforced, it's going to look like this, I think:
User has 1 BTC, 0 unconfirmed, 1.0 available for spending. The 1 BTC is from a single transaction.
User spends 0.5 BTC.
User now has 0.5 BTC, 0.5 unconfirmed, 0 available for spending.
Half an hour later....
User now has 0.5 BTC, 0 unconfirmed, 0.5 available for spending.
This is not going to play well at the mall.
For a big operation with a lot of outgoing transactions, like an exchange, wallet systems may have to have something like active currency management. (This is the "we have too many twenties, and not enough fives right now" problem a retailer sometimes faces).
Anybody thinking about this?
That assumes the user only has a single unspent output available to spend. If a user had multiple unspent outputs they could make multiple txs each involving one or more of them while the new unconfirmed change confirms. My current wallet has 118 unspent outputs so I wouldn't be affected as much by the more conservative version than someone who literally has received Bitcoins once ever.
The patch isn't ideal but it is better than a situation where txs "unexplainably" simply never confirm. The long term goal should be immutable transaction ids however this is a significant challenge and it is going to take a long time. The "fix" proposed would be temporary because doing nothing until the long term goal is reached is not viable. Make no mistake, it isn't ideal, but it is better than what we have right now. I also suggested that it be optional so if users want to risk broken transactions they can spend unconfirmed change outputs. Another optional change would be to have the client create two or more change outputs when the number of discrete unspent outputs (we are talking unique outputs not necessarily value) is "low". This would give the coin selection algorithm more options and (once confirmed) allowed the user to make multiple back to back transactions before needing to wait for a confirmation. You can manually do this yourself (i.e. in your 1 BTC example the user could right now send 0.1 BTC to 10 different addresses in his wallet).