Spec parts and sections that are referencend in below points:
A: NodeId: https://reference.opcfoundation.org/v104/Core/docs/Part3/8.2.1/
B: ExpandedNodeId: https://reference.opcfoundation.org/Core/docs/Part4/7.11/
C: Index: https://reference.opcfoundation.org/Core/docs/Part4/7.13/ (basically, it is "alias" for UInt32)
D: Binary encoding of NodeId: https://reference.opcfoundation.org/Core/docs/Part6/#5.2.2.9
E: Binary encoding of ExpandedNodeId: https://reference.opcfoundation.org/Core/docs/Part6/#5.2.2.10

1. The Part 3 section 8.2.1. (A) says for NodeId that namespaceIndex is UInt16. This is ok and what is used.
2. The Part 6 for the binary encoding of NodeId (D) say the same, ok.
3. The Part 6 for the binary encoding of ExpandedNodeId (E) form is shared with NodeId via the DataEncoding byte, thus via that the namespaceIndex is and must be UInt16 (since basically the ExpandedNodeId is just 2 extra fields of the NodeId encoding form), this is ok.
4. However, the part 4 for ExpandedNodeId (B) defines the namespaceIndex as the "Index" type (C). This is wrong, since the Index type is defined as UInt32, which differs from the UInt16!
5. The serverIndex however is "properly" defined as the "Index" type, since Part 6 (E) says ServerIndex is UInt32.

Thus, I assume it is a typo in Part 4 section 7.11 (B) and it should instead just say "namespaceIndex UInt16", since that is the only explanation that makes sense (since UInt16 is anyway the max index a NodeId could have, so even references to other servers would not change that fact and since Part 3 does say it is UInt16 it is also not "just an encoding optimization" either), plus that UInt16 is what everyone anyway uses (or we would see huge interop problems), so part 4 should reflect the encoding in this case.

Also, as extra note: The UInt16 for namespaceindex and UInt32 for serverIndex are set in stone and cannot basically be changed at this point. However, due to this it might make sense to add a small detail for the ExpandedNodeId that the serverIndex cannot be larger than Int32_max-value-1 (i.e. not UInt32!), since the maximum array index OPC UA can use is Int32_max-value-1 (since 0 is first index) because the length of an array is Int32 (-1 is null array). Or maybe this should be added to the "Index" type's text. It might still make sense modelling-wise since negative numbers might not make sense and UInt16 cannot represent every array index (but I assumed this was an intentional optimization to limit the number of namespaces to Uint16).