I personally call it Ethereum Cash (Ethereum Cash is Ethereum, but more scalable), though @Mikerah hates that name.
I guess the novel-ness over the many many previous side chain ideas comes from the “merged consensus” mechanism. We note that single-operator Plasma is not permissionless, and that block withholding creates big problems (i.e., mass exits for Plasma M[ore]VP). If we had a permissionless consensus protocol that discouraged block withholding, we wouln’t need mass exits and problem solved—moreso if the consensus protocol had similar guarantees as the parent chain’s consensus. To that end, we can take merged mining, cut out re-using proofs of work, and just allow miners (or, more generally, validators) to create both parent chain and side chain blocks in unison. Security is borrowed from the parent chain since what I just described is a commit chain. Essentially, we can use the parent chain as a timestamping server to prevent mining of long hidden chains, which is an endemic problem with merged mining.
An obvious criticism is that the scheme, if scaled to large blocksizes on the side chain, prohibits home users from full validating the chain. I don’t see this as a problem, as the same can be said for sharding: scalability is only achieved in a sharding context because not every client validates every transaction and instead relies on light-client proofs. In other words, the scheme we present makes no stronger assumptions than sharding.
As a bonus, the scheme can be improved by incorporating the data availability of zk-roll_up (i.e., just post all the data to a shard chain), but unlike zk-roll_up it only needs the execution engine to support hashing, not hashing + verification of SNARKs.
As another bonus, the scheme can support any number of parallel side chains (let’s call them parachains for short) using the Ethereum chain to relay information between side chains. Heterogeneous sharding in a PoW context, if you will.