We had a long discussion in Boston over whether $expanded navigation properties were implicitly added to a $select.

The argument against doing this was that it was more correct and simpler to keep the two separate; $expand is part of defining the extent of the result, and $select is used to say which properties are returned. Implicitly adding the expanded navigation properties to the $select would mean a serializer would have to look both in $select and $expand to figure out which properties to put on the wire.

The argument for implicitly adding $expanded properties to $select was that it wasn't meaningful to do a $expand if you weren't going to return the expanded property, so why require the client to add it to the $select?

As strong as the first argument is, we have empirical evidence that customers do get tripped up today by having to add the $expanded navigation properties to $select. OData needs to be simple and predictable, so though I like the cleanliness of keeping them separate I propose we follow the principle of least astonishment by making the expanded navigation properties implicit in the $select.

Note that this means the metadata url has to specify selected or expanded properties, and can't just copy the $select, but we already moved away from just using the $select in the metadataurl in order to handle selects on expanded properties w/o going back to path notation.