I'm getting the impression this issue is related to deltas and that its scope is as such but, to me at least, that is not clear from the description/proposal.

If it is not, just in case, doesn't putting a navigation property in the $select list currently return the navigationLink? And what are we proposing we'd change that too exactly?

Ha; yes, this was intended to be related to delta queries. I have (attempted to) clarify the title and description accordingly.

The question here is what to do if the service represents changes to related entities as inline collections. In that case, specifying a nav property in the $select list (but not $expand) presumably includes inline (minimally) the @odata.ids (or key properties) of the current membership.

Alternatively, client could specify $expand=nav/$ref to say they are interested in related links, but not the contents of those related entities.

Updated proposal based on discussion 2017-1-19. Mike to check whether or not this still addresses scenario that caused issue to be open initially. Semantics of revised proposal are much better aligned, but possible concern is use of $expand=nav/$ref is a bit more esoteric, where use of a nav prop in a select list is very straight-forward.

Approved 2017-1-26

Application approved 2017-6-8.