SSLshopper has a neat little certificate chain checker:
http://www.sslshopper.com/ssl-checker.html#hostname=news.yco...
Surely, moving to another service provider is fully legit. However, a hijack with a rogue certificate (say from an undiscovered Diginotar) would not be visible to users - thereby exposing their credentials. So people use TOFU (trust on first use) mechanisms like Certificate Patrol:
http://staff.science.uva.nl/~delaat/rp/2012-2013/p56/present...
The future is of course DANE with DNSSEC, where you put information about the certificate and/or the CA in the DNS.
I agree that it would make things more secure if it were a best practise. However, it is currently not. Nobody actually does it, and I think you'd be fighting an unwinnable uphill battle to change this.
If you're going to fight this, you might as well deprecate the CA system as best practice while you're at it. Does this sound unlikely? The same problem applies to asking websites to publish a suitable warning.
And how would you securely broadcast such a warning, anyway?
If you're not looking at the whole chain, you're ripe for MITM, particularly with the cruft in default root certificate distributions as well as ongoing changes in entity alliances -- whether free or coerced.
this is just not true
"Browsers trust a very large number of these CAs, and unfortunately, the security of HTTPS is only as strong as the practices of the least trustworthy/competent CA. Before publishing this data, we attempted to notify administrators of all sites observed vulnerable to the Debian weak key bug; please let us know if your analysis reveals other classes of vulnerabilities so that we can notify affected parties."