In OData-876 we defined a format for representing nested changes in-line within a delta format. In OData-613 we said you could use PATCH to update a collection using a delta format, and added the following to ODATA-876:

"You can use contextUrl (ending in /$delta) on the navigation property to specify that the nested content is a delta content (partial update with patch semantics that can contain added/deleted links and tombstones)."

The above text implies that you can have a delta format nested within a navigation property for an otherwise non-delta format. However, this brings up some issues, since the delta format was defined as a flat format. In particular,
1) what is the format/content of the contextUrls required for added links, deleted links, and deleted entries
2) are there any restrictions on the scope of the added/delete links (and tombstones); do they have to be at all related to the nav prop?

Option 1 would be to use contextUrls such as the following:
{
"@odata.type":"#Northwind.Manager",
"FirstName" : "Patricia",
"DirectReports@odata.contextUrl" : "#Employees(1)/DirectReports/$delta",
"DirectReports": [

{ "@odata.context":"#Employees/$deletedEntity", "id":"Employees(3)", "reason":"deleted" }

,

{ "@odata.context":"#Employees/$deletedLink", "source":"Employees(1)", "relationship":"DirectReports", "target":"Employees(4)" }

,

{ "@odata.context":"#Employees(1)/$link", "source":"Employees(1)", "relationship":"DirectReports", "target":"Employees(5)" }

,

{ "@odata.context":"#Employees/DirectReports/$entity", "FirstName": "Suzanne", "LastName": "Brown" }

]
}

Option 2 would be to prohibit use of delta format for nested nav props within a non-delta format.