Thanks for the comments!
Yes, you can use the exact same technique
That would mean that coin 2 needs to have the entire future of their coin, up to block N - 1, before they can authorize a transfer in block N, right?
Yes - this is stated as a client rule in the specification
The client must ensure that before signing a transaction whose block commitment is n, he must have validated all blocks before $$n (i.e., with block number <n).
wrt:
it puts a bottleneck on new block creation—the block operator needs to propagate block N - 1 to every transacting party, and they need to validate it before authorizing their transaction for block N.
That is a disadvantage of this design, although I don’t think it creates a bottleneck, since it increases the computation and bandwidth load on the block producer, but does not asymptotically increase the expected computation and bandwidth load on the client. There is a new requirement that to spend some money the user’s client has to extend his validity proof right to the chain tip. However, in the old design, if a client had a not-so-up-to-date validity proof, yes he can still spend a coin, but the receipient has to update the coin validity proof by checking every block until he finds one that has the transaction. So in terms of the bandwidth/computation requirement of extending a coin validity proof, the new scheme is worse off by a constant factor of 2.
There’s another disadvantage that I didn’t point out in the OP - if there’s a functioning plasma fee market and a sender wants to save on gas (i.e. the equivalent of going to ethgasstation and using the SafeLow fee) he has to keep signing transactions for say a half hour.
If Alice authorizes a transaction to Bob in block N, and the operator withholds block N from them, they don’t know if it’s safe to exit from Alice’s coin (and don’t have a valid proof to allow them to exit from Bob’s coin even if it is included in block N).
That is correct, and included in the definition of atomic transferability of ownership and validity proof. One thing to note is that the limbo exit technique can be incorporated here as well. However, the design is not designed to solve the problem where the operator withholds block and there are many possible committed transaction graphs. I think solving it requires fair exchange (of transaction signature for inclusion in a block), which can only be partially done for e.g. by a commitment from the operator that is enforced on ethereum either in a state channel or out of a shared bounty contract (to be written up). Another is that I do not think the assumption made in Reliable Exits of Withheld In-flight Transactions ("Limbo Exits") that every attempted exit include a slashable/claimable bond is an optimal assumtion - I think a better way might be to have every cancelled exit not give up the bond “by default” and use revocation signatures to allow potential griefers to expose themselves to slashing (to be written up). A third thing to note is that a big problem with confirmations is that it makes it not possible to do general conditional pa (eg paying for fees in plasma MVP using an extra output UTXO) because the plasma chain execution VM can enforce atomic execution of a transaction but not fair exchange of the requisite confirmations. I think we don’t see this problem in plasma cash yet because no designs so far have any conditional payment features, but we will see them once we build more richly-featured plasma cash specs, and limbo exits won’t help solve this.