Clarifications for select-list in ContextUrl

The use of select-list is defined in prose in the Protocol document:

  {context-url}#{entity-set}{/type-name}{select-list}/$entity
  {context-url}#{singleton}{select-list}
  {context-url}#{type-name}{select-list}

We go on to say:

  {context-url}#{entity-set}{/type-name}{select-list}
  {context-url}#Collection({type-name}){select-list}

Questions:

1) We should clarify that, if the contextUrl includes only expanded navigation properties (i.e., only navigation properties suffixed with parens), then implicitly the default set of properties is selected. This is never spelled out, but is implied by our example 22:

Note that, in this example, there is no $select applied to the top level entity (Employees(1)) implying that the default set of properties should be returned for the sales manager, which appears to be implied by the contextUrl only including the expanded properties.

2) What do we mean by "Note that expanded properties are implicitly selected."? Does this mean that expanded properties are implicitly in the response, or does it mean that expanded properties also have their navigation link included? In 4.01 we say that, in the contextUrl, the expanded navigation property must appear with open/close parens in addition to any selected or expanded navigation properties. i.e., if it both selected and expanded, then it appears twice; once with, and once without, the parens. If we read the first statement as "also have their navigation link included" then it seems unnecessary to represent the expanded navigation property in the contextUrl without the parens.

3) Now that we have introduced select options, how do we represent select options within the contextUrl. We already have a syntax for nested select, using path syntax:

select         = ( "$select" / "select" ) EQ selectItem *( COMMA selectItem )
selectItem     = STAR
               / allOperationsInSchema 
               / [ ( qualifiedEntityTypeName / qualifiedComplexTypeName ) "/" ] 
                 ( selectProperty
                 / qualifiedActionName  
                 / qualifiedFunctionName  
                 )
selectProperty = primitiveProperty  
               / primitiveColProperty [ OPEN selectOptionPC *( SEMI selectOptionPC ) CLOSE ]
               / navigationProperty
               / selectPath [ OPEN selectOption *( SEMI selectOption ) CLOSE
                            / "/" selectProperty 
                            ]

This is somewhat more verbose, but it would be breaking (and somewhat ambiguous between dynamic properties with select options and expanded dynamic nav props) to change it to use the parens syntax. But, what about nested expands within $select?

4) We say that explicitly selected functions are also represented in the contextUrl. Should these be represented with, or without, parens?

Looking again at our ABNF, we see that qualifiedFunctionName is defined generally as:

qualifiedFunctionName = namespace "." function [ OPEN parameterNames CLOSE ]

which implies that you could include or omit the parens (we should pick one).
If we don't include the parens, then we can't differentiate between overloads.
If we do include the parens, then how can we differentiate between dynamic functions and dynamic expanded navigation properties?

5) We say that the contextUrl for a collection of references (i.e., Customers/$ref) is #Collection($ref), and the contextUrl for a single reference (i.e., Orders(1)/Customer/$ref) is #$ref, but we don't say how an expanded reference (i.e., Customers?$expand=Orders/$ref) is represented in the contextUrl. Note that defining new syntax for this (for example, Customers(Orders/$ref)) would be a breaking change. Also, it's not really necessary to know about the $ref in order to interpret the results, understand metadata, or materialize missing information in a JSON minimal metadata format. So there may be no need to represent it at all.