RTLS neither supports multiple leaf certificates for a single session nor X509 supports multiple issuers for a single certificate. This means there will be changes necessary on the protocol. But lets just ignore the effort to make such changes and look how much more security we get with your proposal. Lets have a look how a bad certificate might get issued, in which situations your proposal helps and how it compares to existing proposals.
How the attacker can get a certificate
A bad certificate can be issued if the CA is compromised by the attacker, i.e. is buggy, hacked or if the CA employs untrustworthy people. In this case your proposal would help because you hope that not all of the multiple CA's have these problems at the same time. Of course this is not that simple, because you better make sure that the different CA's are actually controlled by different entities and run different code, i.e. that a single hack is not actually a hack of multiple CA.
But an attacker can also get a certificate by compromising the domain validation process. This process works similar for all CA and if the attacker gets access to the mail of the domain owner or the server he might manage to get a certificate for the same server from multiple CA's. In this case your proposal would not help at all. But of course in this case the hacker would only get access to a few certificates for badly secured domains, while in the case of a CA compromise he might get lots of certificates even for domains with good security.
What alternative proposals exist
With certificate or public key pinning (HPKP) a domain owner can make sure, that the certificate uses a specific public key. With HPKP is effect the attacker would need to get access to the private key of the existing certificate, i.e. hack the server. This protects domains with good security against misuse of certificates the attacker created by compromising a CA. The nice thing about HPKP is that it is cheap and easy to roll out and that it is already supported by major browsers.
Certificate transparency is a public log which can be used to find out if a CA issued a certificate which it should not and if a CA is aware that it issued a specific certificate. This can be used by the domain owner to check for rogue certificates. While not all CA's have such logs yet the number is growing because the browser vendors push the support as a requirement to be a trusted CA. For now Chrome requires all EV certificates (green bar) to be covered by such a log and some other CA are also required to issue such logs since they showed to have insecurities in the past. The nice thing is that supporting browsers like Chrome know which CA should have such a log and can check against it.
DANE makes it possible for the domain owner to publish its own certificate in the DNS without the need for CA. Of course this has to be somehow protected against DNS spoofing so it needs DNSSec. DANE can be used both with self-signed certificates instead of using a public CA or with CA signed certificates as an additional protection. While not currently implemented in the browsers it is already used for mail by several providers and support in this area is growing.
While your proposal would be useful to increase the security it needs major changes to the existing TLS protocol (serve multiple leaf certificates) or X509 model (multiple issuers for a single certificate). But at least optional multiple certificates are probably possible to implement with the help of TLS extensions, so we don't need to new TLS version for this. It will increase the data transferred in the full handshake though (lots of leaf certificates and chain certificates) which slows down the handshake.
The alternative proposals don't need such protocol level changes since they work outside the TLS protocol. Also, in the case of HPKP and DANE they provide more control over the certificate to the domain owner than your proposal.
But at the end all of these ideas could in theory be used together to increase the security. And while your proposal would increase the security it is probably more disruptive than the others and would cause more costs, and that's why the others are preferred for now.