Clients should be prepared to handle unadvertised properties

Clients today may see unadvertised properties if a type is marked as open, but open also implies that the client can store properties not defined as part of the type definition.

For extensibility, services should be allowed to return properties not advertised in metadata without marking the type as open (and implying that the service is capable of persisting properties arbitrary properties). This would allow, for example, $select to contain an expression, aggregations to return aggregated values, etc.

We need to define the semantics of these unadvertised properties; i.e., must they be reflected back in a PUT (unless they are annotated as read-only) in order to prevent data loss when roundtripping

Note that, for a request against an open type, the client would have no way of knowing if the property were a dynamic property (which would require specifying in PUT to avoid overwriting) or a property defined, i.e., in $select (which should not be specified in a PUT - note that the server cannot ignore these added properties in general because, if the type is marked as open, the server has no way to know how to distinguish between the client echoing back a read-only property (such as a projected expression) and the client attempting to persist a new open property.