Other examples:
Content-Type. There were a few years where many sites were misconfigured to serve virtually every non-HTML file as text/plain. IE, deviating from the HTTP spec, always used its own algorithm to detect the actual file type and thus "worked", whereas Netscape (and later Mozilla) respected the header and would display "garbage".
Windows-1252 mojibake. Various Windows-based authoring tools simply used the native Windows code page 1252 to encode their text in HTML files, which were then claimed to be encoded as ASCII or ISO 8859-1. This led to documents that mostly looked correct but would have garbage sprinkled around due to added punctuation in Windows-1252 (primarily the distinct open/close quotes and em-dashes, if memory serves). IE of course handled these "correctly", i.e. interpreted ASCII or ISO 8859-1 to mean Windows-1252. I think this behavior is now specified by HTML5 under certain conditions.
You can leave out "under certain conditions", whatwg just plain specifies the "iso-8859-1" label identifies the windows-1252 encoding [1]
Middleboxes are considerably more problematic, since you've got a lot of manufacturers out there, some of them might actually be out of business. Pushing firmware upgrades to all of those middleboxes would also be a nightmare. And the icing on the cake is actually finding the malfunctioning middleboxes, since they can be anywhere between the end user and the web server.
No. Every website that uses a Symantec cert (that was issued before 2017-12-01) needs to renew their cert early to move to their new root.
We've been there with CSS box model, DOM levels, (X)HTML(5), and CSS prefixes. There have been some cases of cooperation, e.g. SHA-1 certs and kicking of bad CAs, but most of the time browser vendors only "break" things gradually and only when it affects < 0.1%.