Simple Summary
Two new transaction types for wrapping legacy transactions with and without a chain ID.
Abstract
Introduces two new EIP-2718 transactions that are signature compatible with legacy transactions and can be automatically upgraded by any client.
0x00 || yParity || r || s || 0x65000000 || rlp(nonce, gasPrice, gasLimit, to, value, data)
0x01 || yParity || r || s || 0x65000000 || rlp(nonce, gasPrice, gasLimit, to, value, data, chainId, 0, 0)
A few questions:
That would be a discussion to have regarding mainnet inclusion, which I believe is now handled over at the eth1.0 specs repository now. 
That being said, step 1 for deprecation is to provide a new option. The sooner we do that, the sooner we can start the next steps of the deprecation process (such as defining an end of life date and a mechanism for slowly killing off stragglers).
Yes, it is commonly used to create deployment transactions that can be executed on all chains at the same address via a vanity signature (create signature by hand, recover address, send ETH to address, submit transaction). There are EIPs out there that provide a bettere way to achieve that, but they aren’t available yet.
Even if we didn’t want that, in order to ensure that someone with a signature from before EIP-155 can still submit that transaction to the blockchain we have to continue supporting both formats. There is a strong desire to ensure that someone who has an old hardware wallet or something doesn’t lose the ability to sign transactions.
Agreed! Unfortunately, I’m not the right person to do this. Would love to get some help fleshing out the Rationale by someone more knowledgeable than I on why SSZ!
I also see that yParity is expected to be either 0 or 1. What is the rationale for departing from the standard 27 or 28 used by Ethereum today (tbh, not sure where those numbers came from – best I’ve only found this explanation by Peter)?
Edit: from the yellow paper:
It is assumed that v is the ‘recovery identifier’. The recovery identifier is a 1 byte value specifying the parity and finiteness of the coordinates of the curve point for which r is the x-value; this value is in the range of [27, 30], however we declare the upper two possibilities, representing infinite values, invalid. The value 27 represents an even y value and 28 represents an odd y value.
Unless there is a strong motivation to deviate, I think it is best to v to continue being either 27 or 28.
The rationale is that it is a point of confusion and a source of bugs in integration software and there was no good reason for 27/28 in the first place. It was an artifact of copying Bitcoin that just kind of meandered its way into Ethereum and has confused developers ever since. One nice property of 0/1 is that you can treat it as a boolean in code, which results in code like yParity ? x : y rather than v == 27 ? x : y which is not only marginally simpler, but also more intuitive since the variable name now actually makes sense to anyone familiar with the concept of parity in mathematics.
I think everywhere else we save signatures in the order of r, s, v (yParity) so maybe better to do the same here?
This EIP no longer specifies a new transaction type. However, the feedback still applies to new EIPs that do. In the transaction signatures previously, it was v,r,s I believe? Also I think byte array encoded signatures also lead with the parity byte? Where does parity byte come last?