In principle, transactions can be in multiple blocks can't they?
If two miners both include the same transcation in a block based on a common ancestor?
If this happens, the block chain split and one of the blocks will be orphaned later when the network decides which chain to take. It's impossible for one block to be a descendant of another and have them both include the transaction; the descendent block would be invalid.
The validity or not of a transaction is independent of whether its in a block or not. Eventually one of those blocks will be built on by the rest of the network and the new "true" block tip decided upon. Strictly, it is blocks that are "confirmed" not transactions.
This statement is correct on its surface, but there is one thing you are not taking into account -- double-spending. Just because you have transaction X that spends coins Z doesn't mean that there isn't another transaction Y floating around the other half of the network spending the same coins Z. Once one of them makes it into a block, clients that receive that block will look at the other transaction and conclude it is invalid since it spends already-spent coins, and drop it (or mark it invalid, but either way it won't be treated as valid). The deeper a transaction is in your client's view of the block chain, the less likely that there is an alternate block-chain in existence that spends the same coins. So six deep was decided as a reasonable amount to consider a transaction "fully confirmed," since it implies that about an hour has passed without seeing an alternate chain. This is more than enough time to reconcile legitimate orphan block chains. (If someone split from the network with the intent to create an alternate block chain that would invalidate a transaction included over six levels deep in the main block chain, they will either need more computing power than the rest of the network or a crazy amount of luck.)
Therefore you can't have transaction lists include a block hash, as it's possible for them to be in more than one, at least temporarily. Since it is blocks that get confirmed, each of those transaction-block links would also have a different number of confirmations.
Yes, but your client sees only one
of those conditions. The client will not consider a transaction to be in two blocks, not in any meaningful way. I'm not quite sure what you are getting at here -- exactly which part of either algorithm I have presented breaks down in the case where an already-processed transaction changes blocks?