From crypto perspective, there is nothing new at all - and that's exactly the point :-).
The idea is not to invent crypto, but rather to start using well-known-but-not-really-used crypto constructs in practice (hey, why nobody out there uses 2-layer TLS+SSH? With proper deployment, it would improve security significantly even w/o any obscurity.)
Without proper deployment - all the security in the world is perfectly useless; are you arguing to abolish it entirely?
Class breaks are super useful for script kiddies, in that someone can write a piece of code once and it'll work against any software in that class. Your idea would mitigate this slightly by turning each application into its own class which would have to be broken separately.
Yep.
The problem is, for applications that are interesting enough to break (like banking software), breaking X-TLS is not harder than breaking TLS.
That's arguable - and the whole argument is inherently subjective too; see my side of the story below. As for "who should be the judge in this argument" - well, I'm already receiving positive feedback from banking/state-lottery/gaming guys; among them - there are two Quite Senior Guys from banking security industry (both Security Chief Architects of their respective banks, and one - of a top-20 bank) who have said that they're interested in the concept of making protocols unique; this IMO should count for something in an inherently subjective argument about the best interests of the banking industry ;-).
All of this requires that the attacker has broken TLS in the first place, which is already a much, much harder problem.
Here is the important point you seem to be missing. In modern hacking world, in 99% of the cases it is not the same person who actually broke TLS (or whatever-else-library) and the person mounting the attack - but there are two different people: (a) the one breaking-something and selling attacks (zero-day or otherwise), and (b) the one mounting the attack. The whole modern hacking economy is centered around this specialization - and as it was discussed in Part I, this specialization is exactly the thing aimed by making protocols unique (="separating classes"). Yes, there are guys out there who can eat obscurity for breakfast - BUT most of the time they're not the same guys as the attackers, so adding them into the picture will significantly increase attack costs - and increasing attack costs is the only thing security is about. And we didn't even start to discuss such very practical effects that "it is not necessary to run faster than the bear, it is sufficient to run faster than the guy next to you".
P.S. And BTW, two-layer security is still significantly better than a single-layer one, even without obscurity in the picture.
I take that there are no further arguments about the additional value of obscurity, right? ;-)
Now to dual-crypto (some of variations of which are BTW recommended by no less than Schneier - with provable guarantees that combination is at least as secure as BOTH A and B - and this schema is referenced in OP too; normally, however, dual-crypto is at least as secure as the "inner" encryption - as formally proven in Maurer-Massey and discussed in Schneier/OP - but this is "good enough" for our purposes).
When it comes to secure channel, I can offer one very practical combination: TLS(SSH(M)). As for side channel attacks - unless side channel attack exists for SSH - good luck finding it for this combination; moreover - this combination is provably "at least as secure as SSH" (with proof going along the same lines as Maurer-Massey, or informally - if we could make SSH less secure by adding another layer on top of it without any knowledge about internals - which is doable by attacker too - SSH security would be in a Big Fat Trouble to start with).
And sure - w/o obscurity TLS as such is still vulnerable to Heartbleed, but the point is that if we managed to get the app-with-TLS(SSH) to the Client intact (for example - using signature verification, which is already available on 90%+ end-user devices worldwide, and nothing prevents from building it into browsers too) - Heartbleed won't be able to get SSH private key (that's where "properly deployed" comes in - to be on a safe side, TLS and SSH should run on two different boxes server-side), so the system as a whole would stay intact. And even if Heartbleed-equivalent would exist for SSH - we would still be ok (as stealing just an SSH private key wouldn't be enough to impersonate the TLS(SSH()) server as a whole).
In a sense - to certain extent, yes (though it is more like VPN-for-regular-customers rather than usual VPN-for-admins).
EDIT: OTOH, the whole thing is not just like VPNs: (a) it is applicable to other crypto primitives dual RNGs (helping against things such as Debian RNG disaster), and (b) it allows for added obfuscation (which makes attacks even less feasible).
Would Xor'ing 2 PRNGs affect the distribution? Increasing/Decreasing the chances of certain numbers?
Looks to be logical but all that is well-known. What's new?