The current specification of the RelatedTo filter operator and the related examples in Annex B.2.4 leave some room for interpretation and should be clarified.

Concerning the normative part:
1) The spec says that a nested RelatedTo operator "returns a list of NodeIds instead of TRUE or FALSE". However, the nature of these NodeIds is not specified. I assume that a nested RelatedTo operator should return the NodeIds of matched instances and not NodeIds of types (which types should that be?) as is currently specified. But practically speaking I do not see the point in returning a list of NodeIds instead of a boolean value since an implementation will likely evaluate nested RelatedTo operators not in strict depth-first order, otherwise all nodes in the address space would have to be evaluated for each occurrence of a nested RelatedTo operator.
2) If the assumption in 1) is true, is operand 4 to be ignored with nested RelatedTo operators?
3) The spec says that operand 3 (number of hops) shall be of type Int32 but does not specify what happens if this number is negative. A UInt32 type might be more appropriate here.

Concerning the examples in B.2.4:
4) All examples illustrating the use of the RelatedTo operator make use of AttributeOperands to define a NodeId of a specific type. For example, operand 0 of a RelatedTo operator is defined as:
"AttributeOperand =
Nodeid: PersonType,
BrowsePath “.”,
AttributeId: NodeId"
This would however select all nodes which are hierarchically referenced by the currently evaluated target node (which must be of type PersonType), hence return a list of NodeIds which is an invalid argument for the RelatedTo operator. I think all AttributeOperands should be replaced by LiteralOperands pointing to the NodeId of the type.
5) Many examples use invalid AttributeIds like "Period" in Example 3. I guess this is the name of a component and should be moved to the BrowsePath.