Nailing object property order

[Bergi]

Tab Atkins Jr. schrieb:
> On Wed, Apr 15, 2015 at 6:39 PM,  <a.d.bergi at web.de> wrote:

>> What was the motivation to pin these down in ES6?
>
> Because, for objects at least, all implementations used approximately
> the same order (matching the current spec), and lots of code was
> inadvertently written that depended on that ordering, and would break
> if you enumerated it in a different order.  Since browsers have to
> implement this particular ordering to be web-compatible, it was
> specced as a requirement.

I see, that makes some sense at least. But why was the default object 
[[enumerate]] algorithm not specced to match the [[OwnPropertyKeys]] 
order then?
Most, if not all, of the codes I've seen that unfortunately depend on 
this insertion-order ordering do use simple `for in` loops (sometimes 
accompanied by a `obj.hasOwnProperty` check, very rarely an 
`Object.prototype.hasOwnProperty.call` check). None iterated over the 
`Object.keys` or even `Object.getOwnPropertyNames` array.

Shouldn't we add a guarantee to [[enumerate]] that the subset of 
enumerated *own* properties comes in insertion order as well? That would 
still leave open to engines how they deal with inherited properties.
Similarly, we remove step 6 ("*Order the elements of names so they are 
in the same relative order as would be produced by the Iterator that 
would be returned if the [[Enumerate]] internal method was invoked on 
O.*") from `EnumerableOwnNames` (`Object.keys`)?

  Bergi