Original text:
A type is a set of instances.  A type is a subtype of another type if its set of instances (possibly after coercion) is a subset of the set <del> of instances of the other type. </del>  tbl-types defines the available types in terms of abstract instances, where "n" denotes a node, "v" denotes a value, and "nl" denotes a <del> non-empty nodelist.  The table also lists the subtypes of each type. </del>  Notes:

Reviewer comments:
Fixes URL
is a subtype by coercion of , but Table 13 does not include this subtype relationship.
Not sure I like the concept of "subtype by coercion". One can be used in place of the other as it can be coerced, but that is not usually what we'd call a subtype.
That's a different point really. Table 13 already includes at least one subtype by coercion, so this issue adds another subtype by coercion.
NAME How would you like to proceed with "subtype by coercion"? If we want to explore alternatives, I think it deserves a separate, non-editorial issue.
From the spec, just below : I disagree with the idea that coercion implies subtypes. If I have integer and floating point numeric types, I can cast from one to the other, but that doesn't mean that either is a subtype of the other. C# provides "implicit" casts where the compiler can infer a type cast from context. For example, I think this is closer to what we're dealing with here. We're looking at compatibility and conversion between types, not polymorphism (as "subtype" implies).
If I'm reading the right, it looks like the term is being used to mean different things depending on which column it's in. In column 1 ("Type") or column 3 ("Subtypes"), it's referring to the type system we're creating. In column 2 ("Abstract Instances"), it's referring to the underlying JSON(ish) value kind, i.e. , , , etc, plus . I think having the same word to define these things can be confusing for the reader, and maybe we need something else in one of these places to indicate the distinction. We've already done this for the type to distinguish it from the value.
I'm not sure there is a really good alternative. We could use for abstract instances, but in the rest of the spec, "value" implies a JSON value, so this doesn't seem quite right.
If "value" implies a JSON value (corresponding to the middle column), then we should change the others (the type name). It really is confusing.
In the interim, we decided to append the type names with "Type". I will create a PR for this.
I'm going to wait for to complete before going forward with this as they change the same chunk of text.
Thanks. That's why I am trying to tidy up and get it merged ASAP.
(Modulo the coercion entry on OptionalValue, as discussed.)

Revised text:
A type is a set of instances.  A type is a subtype of another type if its set of instances (possibly after coercion) is a subset of the set  <ins> of instances of the other type.  The subtype relationship is transitive: for any A, B, and C if B is a subtype of A and C is a subtype of B, then C is a subtype of A. </ins> tbl-types defines the available types in terms of abstract instances, where "n" denotes a node, "v" denotes a value, and "nl" denotes a  <ins> non-empty nodelist.  The table also lists the (immediate) subtypes of each type. </ins> Notes: