允许重复的属性名称的目的是什么？

我正在读MDN JavaScript 参考，因此下面的代码不再返回false:

function haveES6DuplicatePropertySemantics(){
  "use strict";
  try {
    ({ prop: 1, prop: 2 });

    // No error thrown, duplicate property names allowed in strict mode
    return true;
  } catch (e) {
    // Error thrown, duplicates prohibited in strict mode
    return false;
  }
}

在 ECMAScript 5 严格模式代码中，重复的属性名称是 被视为语法错误。随着计算属性的引入 运行时可能出现重复的名称，ECMAScript 6 已删除 这个限制。

我的问题是，在初始化程序中允许重复的属性名称有什么实际好处？我可以看到，当动态分配对象属性时，有时可能会发生这种情况，但由于优先顺序显然决定了新创建的对象上实际设置的属性 - 这似乎比最好避免的不确定行为更重要。

在初始化程序中允许重复的属性名称有什么实际好处

没有任何实际好处。既然 ECMA Script 6 中有计算属性键，键的实际值将仅在运行时确定。事实上，键可以在运行时添加到对象中，并且它们会覆盖现有的键和值。 ES-6 中扩展了相同的行为，并且删除了不允许编译时重复键检查的限制。

引用艾伦·维尔夫斯-布洛克 (Allen Wirfs-Brock) 的ESDiscuss 邮件列表中的讨论,

计划是对包含计算属性键和当前规范的任何对象文字执行运行时验证。草稿包含用于执行检查的伪代码。然而错误报告（https://bugs.ecmascript.org/show_bug.cgi?id=1863）指出当前规范的问题。例如，当前的规格。抛出错误：

({get a() {},
  get ["a"]() {}
});

但不在：

({get ["a"]() {},
  get a() {}
});

基本上，在处理包含计算键的属性定义时，仅检查已定义的属性键是不够的。如果存在任何计算键，则即使对于具有文字属性名称的定义也必须进行检查。仅仅考虑属性键和数据/访问器属性的区别是不够的，验证还必须考虑定义的语法形式以及是否适用严格模式..

事实证明，即使在伪代码中，这也是一组相当复杂的运行时验证规则。我很难说服自己这种动态验证的运行时计算和元数据成本是合理的。成本太高，而实际收益却很小。

出于这个原因，我建议我们放弃对象文字（和类定义）的运行时验证。对于没有计算键的属性定义，我们仍然会有静态验证和早期错误。但是，任何通过这些检查的内容（包括具有计算名称的所有属性定义）都会按顺序处理，不会进行重复名称检查。

因此，建议保留对普通键的编译时检查，并且根据这个评论支票后来被放弃了。在修订版26,

消除了对象文字和类定义的重复属性名称限制