Bring together all the prose about ObjectLiteral being a cover for Ob…

…jectAssignmentPattern.

spec.html

@@ -18401,17 +18401,7 @@ <h2>Syntax</h2>
         <p>|MethodDefinition| is defined in <emu-xref href="#sec-method-definitions"></emu-xref>.</p>
       </emu-note>
       <emu-note>
-        <p>In certain contexts, |ObjectLiteral| is used as a cover grammar for a more restricted secondary grammar. The |CoverInitializedName| production is necessary to fully cover these secondary grammars. However, use of this production results in an early Syntax Error in normal contexts where an actual |ObjectLiteral| is expected.</p>
-        <p>For example, consider:</p>
-        <pre><code class="javascript">
-          let o = {f = 1};
-        </code></pre>
-        <p>`{f = 1}` is parsed as an |ObjectLiteral| with a |CoverInitializedName|, which results in a Syntax Error via one of the early error rules in the next section.</p>
-        <p>In contrast, consider:</p>
-        <pre><code class="javascript">
-          ({f = 1} = {f: 2});
-        </code></pre>
-        <p>Here, `{f = 1}` is again initially parsed as an |ObjectLiteral| with a |CoverInitializedName|, but since it's the |LeftHandSideExpression| of an |AssignmentExpression|, it must cover an |AssignmentPattern|, so the |ObjectLiteral| and |CoverInitializedName| are not subject to early error rules. Instead, `{f = 1}` is reparsed as an |ObjectAssignmentPattern| with an |AssignmentProperty|, and there is no Syntax Error.</p>
+        <p>See the next section for the significance of |CoverInitializedName|.</p>
       </emu-note>
 
       <emu-clause id="sec-object-initializer-static-semantics-early-errors" oldids="sec-__proto__-property-names-in-object-initializers">
@@ -18445,7 +18435,18 @@ <h1>Static Semantics: Early Errors</h1>
           </li>
         </ul>
         <emu-note>
-          <p>This production exists so that |ObjectLiteral| can serve as a cover grammar for |ObjectAssignmentPattern|. It cannot occur in an actual object initializer.</p>
+          <p>Elsewhere in this specification, there are early error rules that, under certain circumstances, require that a |LeftHandSideExpression| must cover an |AssignmentPattern|. Consequently, |ObjectLiteral| serves as a cover grammar for |ObjectAssignmentPattern|. The |CoverInitializedName| production is necessary to fully cover |AssignmentProperty|, but is not valid within an actual object initializer.</p>
+          <p>Specifically, in a context where an actual |ObjectLiteral| is expected, the above early error rule prevents the use of |CoverInitializedName|. But in cases where |ObjectLiteral| is used as a cover grammar, the semantics of "must cover" state that the Parse Nodes within the |ObjectLiteral| are not subject to early error rules, and so |CoverInitializedName| is allowed.</p>
+          <p>For example, consider:</p>
+          <pre><code class="javascript">
+            let o = {f = 1};
+          </code></pre>
+          <p>`{f = 1}` is parsed as an |ObjectLiteral| with a |CoverInitializedName|, which results in a Syntax Error via this early error rule.</p>
+          <p>In contrast, consider:</p>
+          <pre><code class="javascript">
+            ({f = 1} = {f: 2});
+          </code></pre>
+          <p>Here, `{f = 1}` is again initially parsed as an |ObjectLiteral| with a |CoverInitializedName|, but since it's the |LeftHandSideExpression| of an |AssignmentExpression|, it must cover an |AssignmentPattern|, so the |ObjectLiteral| and |CoverInitializedName| are not subject to early error rules. Instead, `{f = 1}` is reparsed as an |ObjectAssignmentPattern| with an |AssignmentProperty|, and there is no Syntax Error.</p>
         </emu-note>
       </emu-clause>