Should @odata.id be bejString or bejResourceLink

The issues with using nnint to represent the odata.id is that there may be "paths" to a device owned resource that the MC is not aware of. As an example, consider a storage controller that provides a Port resource via RDE. The full URI (odata.id) to the Port resource as prescribed by Redfish OpenAPI is:

/redfish/v1/Systems/{ComputerSystemId}/Storage/{StorageId}/StorageController/{StorageControllerMemberId}/Ports/{PortId}

Here, "/redfish/v1/Systems/{ComputerSystemId}/Storage/{StorageId}/" part of the URI is only known to the MC and "StorageController/{StorageControllerMemberId}/Ports/{PortId}" is only known to the device.

If the BEJ data returned by the device only contained an nnint that represents the resource id of the Port, the MC would have no way to construct this full URI.

To partially solve this problem, we introduced the notion of subURIs in the Redfish Resource PDRs. However, we came across scenarios where the MC's cache of Redfish Resource PDRs may not be in sync with the device especially if the MC does not support asynchronous eventing.

To prevent the case where a BEJ payload could contain a resource id that the MC does not (yet) know about,  all odata.ids need to be constructed by the device as a bejString. It would use a deferred binding string (for the MC part of the URI) and a normal string for the device part of the URI e.g.

     "%L<resource-id-of-top-level-storage>/StorageController/{StorageControllerMemberId}/Ports"

This is worrying. I get a feeling the spec might be melting a bit. 

Followup questions then:
1) Is the BEJResourceLink datatype obsolete then? Will it be removed from DSP0218 because of redundancy or are there legitimate use cases for bejResourceLinks that cannot be achieved by the bejString representation?

2) How did it come to pass that desynchronized BMC<->RDE PDR repositories are a permissible situation? There's polling and events to make sure the BMC synchronizes in time. If the BMC still encounters unknown resources it can retrieve the PDRs post-operation, no?

I am assuming that resourceIDs are not recycled within an RDE device - my RDE Toaster will always have a resourceID of 1, BreadSlots under 100 and 101 and BreadSlices will always be under resourceIDs 200 and 201. If BreadSlice 200 is removed, that resource will remain empty until a BreadSlice is inserted into that slot again, whereupon it will appear as resourceID 200 again. Is this method of operation not universally true for all RDE devices?

If the concern is a TOCTOU situation where a resourceID cannot be decoded into a valid URI, then the situation is effectively still present with the bejString odata.id, since there's nothing preventing the user from removing a BreadSlice post-operation anyway, leading to a 404 URI. Worst case scenario is by the time the BMC gets the PDRs, it cannot match the ResourceID, so cannot construct a URI, so points the URI to some generic "Resource no longer exists" landing page.

Ultimately, if PDRChgEvents and polling isn't enough to guarantee PDR repo sync, the BMC can just supply a checksum of it's PDR repository to OperationInit - and if that doesn't match, reject the operation and demand a PDR refresh from the BMC. A race condition is still possible if the RDE device doesn't support atomic reads though. 

3) It appears that now the PDRs - the parts about related resources, subURIs and all resources which are not root-level (parent=System) specifically, are redundant. If the BMC is supposed to function fine with outdated/missing PDRs, then what purpose do they serve? What if there's a mismatch between URIs supplied via odata.id versus constructed by BMC from PDRs? Which takes precedence? What purpose do those of lesser precedence serve?