docs: Spec clarifications (#738)

A couple of small clarifications suggested by Will.

specification/hugr.md

@@ -1234,7 +1234,9 @@ Note that considering all three $\mu$ lists together,
    - the `TgtNode` + `TgtPos`s of all `NewEdgeSpec`s with `EdgeKind` == `Value` will be unique
    - and similarly for `EdgeKind` == `Static`
 
-The well-formedness requirements of Hugr imply that $\mu\_\textrm{inp}$ and $\mu\_\textrm{out}$ may only contain `NewEdgeSpec`s with certain `EdgeKind`s, depending on $P$:
+The well-formedness requirements of Hugr imply that $\mu\_\textrm{inp}$,
+$\mu\_\textrm{out}$ and $\mu\_\textrm{new}$ may only contain `NewEdgeSpec`s with
+certain `EdgeKind`s, depending on $P$:
    - if $P$ is a dataflow container, `EdgeKind`s may be `Order`, `Value` or `Static` only (no `ControlFlow`)
    - if $P$ is a CFG node, `EdgeKind`s may be `ControlFlow`, `Value`, or `Static` only (no `Order`)
    - if $P$ is a Module node, there may be `Value` or `Static` only (no `Order`).
@@ -1262,7 +1264,8 @@ The new hugr is then derived as follows:
 6.  For each node $(n, b = B(n))$ and for each child $m$ of $b$, replace the
     hierarchy edge from $b$ to $m$ with a hierarchy edge from the new copy of
     $n$ to $m$ (preserving the order).
-7.  Remove all nodes in $R$ and edges adjoining them.
+7.  Remove all nodes in $R$ and edges adjoining them. (Reindexing may be
+    necessary after this step.)
 
 ##### Outlining methods