You don’t get perfect fungibility—you get “capped” fungibility. Remember, you can only receive money in a Plasma-Debit-style payment if you have a coin/channel with the operator. Effectively, every incoming payment is actually from the operator, and every outgoing payment is to the operator. These limitations are what allow us to preserve almost all of the per-coin-isolation of Plasma Cash.
Suppose Alice and Bob own coins on a Plasma Debit chain. Alice and Bob are obviously aware of the history of their own coins, and know that they are valid. Bob’s coin has some receiving capacity (i.e., the operator owns some of the balance in that coin).
Alice makes a Plasma Debit payment to Bob. That takes the form of an atomic transaction where Alice pays the operator by decrementing her balance in her coin/channel, and the operator pays Bob by incrementing the balance in Bob’s coin/channel. This transaction is signed by both Alice and Bob. For this transaction, Bob doesn’t care if the history of Alice’s coin is valid! He only cares that his own coin’s history is valid (which he already knows, up to the present), and that the balance in his coin goes up. For this reason, even after this transaction, there is no way for someone to challenge the history of Bob’s coin by showing something invalid in Alice’s coin’s history.
Now suppose you are a later recipient of Bob’s coin, validating its history. You see this transaction where Bob’s balance was incremented—effectively, a payment from the operator to Bob. You shouldn’t (and don’t) have to check anything about Alice’s account (either the validity of its history or even whether the transaction was included in Alice’s slot) to consider this a valid transaction with respect to Bob’s coin, because any malfeasance could only be committed by the operator, and would only hurt the operator.
Next let’s suppose you are a later recipient of Alice’s coin, validating its history. The only thing you need to check is that the transaction was also included in Bob’s slot in the same block. If the history of Bob’s slot is invalid, that’s Bob’s problem! As far as Alice was concerned, she sent him the money.
I’d thought that this requirement would actually need to be more onerous, due to the possibility that the operator could insert an invalid transaction, such as a spend from a prior owner, into Bob’s slot before including this transaction, thus cheating Bob by forcing him to exit from the previous state, where his balance was unincremented. But I just realized that reverting from the exit game that I proposed here to the one initially proposed by Vitalik should address it, because it prevents an exit from being challenged by some non-double-spend invalid transaction inserted between the transaction and its parent.