The problem-behind-the-problem here is: is it possible to have the consensus defined as a written spec. This point is surprisingly controversial because, compare with e.g. internet protocols like TLS: they have a written spec to which all clients adhere. Even there, it's not cut and dried, there are lots of minor details and extensions where there at least could be a server-client mismatch and connections get dropped. But here's the difference: bitcoin's consensus requires byte-for-byte and bug-for-bug 100% compatibility between every peer, it is not a question of pairs of nodes agreeing temporarily, it is a question of every node everywhere and always agreeing. It's possible that neither written specs, no matter how thorough, nor well written code, can meet that standard (a perfect practical example is the 2013 chain split, which was not caused by any of the C++ consensus code per se, but by an unforeseen behaviour in the database software used. Not intentional but unintentional consensus dependency).

ETH from the beginning chose to base things on a written spec, and to my mind this was not wrong, but I am pessimistic that it actually changed anything. If there is an actual open-to-interpretation thing that happens, you're kind of better off having one overwhelmingly used client, as it's a de facto tiebreaker on the debatable thing. The counterargument is, if the overwhelming client has a consensus break that's clearly just an error/bug, then it's nice if there's another client everyone can switch over to as an emergency.