Allow using instance annotations of type (collection of) primitive or complex in $select and instance annotations of type (collection of) entity in $expand.
Example
GET Stuff?$select=@Core.Messages($top=5)
Services can signal this capability to clients with the tagging term Capabilities.AnnotationValuesInQuerySupported.
<Term Name="AnnotationValuesInQuerySupported" Type="Core.Tag" DefaultValue="True"
Nullable="false" AppliesTo="EntityContainer">
<Annotation Term="Core.Description"
String="Supports annotation values within system query options" />
</Term>
Annotations in $select must be included in response and take precedence over preference header; if $select says to include, and preference says omit, it's still included. preference header can add additional annotations to what is specified in $select.
In the presence of both include-annotations preference and annotations selected in $select, then preference-applied, if present, reflects the set of annotations added by the preference-applied (not by $select). In the absence of the include-annotations preference header, there should not be an include-annotations in the preference applied.
Explicitly selected (expanded) annotations must appear in the contextUrl as other properties. It is possible to select only annotations, in which case only those selected (expanded) navigations appear in the result. Note that annotations specified in include-annotations do not appear in the context Url, and do not affect the selected/expanded properties.
It is not valid to $select an entity-valued annotation (because we do not currently define a canonical navigation url for an entity-valued annotation). entity-valued annotations can be included using $expand.
If the annotation isn't applied to the instance, a null value is returned (same as for dynamic properties).
Note that selecting control information (@odata.type, @odata.navigationLink, etc.) is not allowed.
Improvement
Major