Without actually digging into it (I'm on vacation damnit), I'm pretty sure all renderings are valid per CSS 2.1 (though I don't think they are per CSS UI 3 or 4? but maybe that's still a SHOULD level requirement given people wanting to publish as REC ).
The CSS WG has been pretty poor at actually tightening up specification for old features (on the face of it, due to lack of editorial time, which really points at a separate problem).
(Also, given the for(in) example, as I'm sure you know but for the benefit of others, note that iteration order of each object on the prototype chain is still undefined, and not interoperable.)
Some other good examples of things that have been standardised over the past decade: HTML parsing(!), what specific DOM exceptions are thrown all over the place, when the various document load events fire.
But behavior when you deleted an own property that shadowed a property on the proto chain, and what happens when you add such property back.
Also the historic spec mandated integer properties on regular objects were iterated in insertion order as well, but V8 chose not to implement that as doing so broke their "Indexed properties are just an array" semantics. Because of the huge perf impact other browsers had to go down that same path.
One of the goals of all the web related committees for more than a decade has been to ensure that there is no undefined behaviour. Undefined behaviour is exactly the reason we used to have to have different versions of a webpage for every browser.
The only intentionally remaining ambiguities are in areas where there is significant existing content that depends on mutually incompatible behaviour, eg: content that does one thing in browser A, and another in browser B, but is using the same API in each path yet expecting different behaviour. I can’t recall any specifics off the top of my head any more, but a classic has always been for(in) enumeration along the prototype chain when properties are being added and removed. @dbaron or @brendaneich (that his account? I can’t recall) may recall some of the others. Prefixes (that everyone on HN hates) solved this problem - it makes it possible to keep that old non-spec API around, without permanently screwing up the final specification (every points to those old -webkit-gradient properties, but forgets that that api was much clunkier to use than the final gradient spec. If the prefix hadn’t existed then the webkit api would be the permanent one that everyone would have to use)
The other big one where there’s specified behaviour that is allowed to vary is webgl. I was kind of responsible for the hated “only support the minimum subset” rules of version 1, but I believe modern specifications allow an implementation to vary according to hardware. The only other place in webgl that I made people (gpu engineers mostly) unhappy was not allowing undefined behaviour when accessing beyond the end of an array in the shader - there were voices that literally wanted to allow this to be undefined for perf reasons even when shown you could read data from other execution environments (this was mind blowing). The compromise in the end was allowing an implementation to return either zero, or some other constant defined value (I think this would fall under the C/C++ “unspecified” behaviour banner).
Anyway, in general undefined behaviour is bad on the web, and all web spec authors try to ensure that every edgecase is covered explicitly so that we never get stuck back in the terrible 2000s again.