The goal of the Map feature is to create a primitive to JavaScript that does not exist today and cannot be efficiently emulated. In particular, it allows the u

The goal of the Map feature is to create a primitive to JavaScript that does not exist today and cannot be efficiently emulated. In particular, it allows the use of arbitrary, non-string keys. Objects (commonly used as Maps) can have only String keys. In contrast, desiring a way to `get` a nested String value is easily emulated in terms of current JavaScript semantics. In Ember, for example, obj.get('some.nested.path') works in all browsers because it does not require any new primitives. Observers are a similar story. `Object.observe` adds a new primitive to the language: the ability to receive asynchronous notifications about changes made to some object. On top of that, it is possible to implement semantics for nested objects and "computed properties". The Ember team has already been exploring how to incorporate Object.observe into Ember's observer system when it is more broadly available. We support observing nested paths, and the Object.observe primitive gives us enough to build what we need on top. You can expect that if certain patterns on top of these primitives become popular, TC39 will consider them in future versions of the specification.