FieldRef is used for matchable paths. A $match can be on an field with an empty name such as {$match: {"": 1}}. 

FieldPath is the paths that a FieldPathExpression can reference. The path "$" is not valid. It is more restrictive and used in the pipeline module.

canPathBeArray support both, since ExpressionContext is used for all queries. One overload currently converts FieldRef to FieldPath and calls the other with it.

The schema type methods should also support both. The canPathBeArray itself also checks the schema type when available.

Currently we want to know the arrayness of a field, the graph will construct a std::string from the path components, then will convert it to a FieldRef to call ExpressionContext::canPathBeArray, which will convert it to a FieldPath, and call the main overload, then the overload will reach the schema type logic which will take the FieldPath and convert it to a FieldRef, to call Type::canPathBeArray(FieldRef).

std::string -> ExpCtx::canPathBeArray(FieldRef) -> ExpCtx::canPathBeArray(FieldPath) -> Type::canPathBeArray(FieldRef)

This is completely pointless conversion and makes choosing the path type annoying and contrived for every new method. It makes the code error prone since FieldPath validates more strictly and requires early-returns with defaults.

Let's add a lightweight PathView type, which should provide an iterator interface over either of those types. Then we can avoid all conversion and support both types of inputs.