MC behavior while RDE device is not accessible

For pcie/ocp cards at least, you should be able to talk to the device even if it's running on 3.3v / D3Hot only. PCIe/MCTP will be down of course, but SMBUS/MCTP should be up. In that case, the device may have some property value nulls and Resources missing (with whatever +12V needs being unpowered and it's state unknown/not relevant).

If there's no way for the BMC to access the device, then probably the BMC should remove it from the Redfish hierarchy altogether. This should be part of BMC's PLDM logic not strictly RDE though - if a device doesn't meet PLDM base requirements for responding in time and retransmission count is exceeded, it should be dropped as a PLDM device - as a consequence, dropped as an RDE device - and as a consequence, it's Resources unplugged from the BMC-owned hierarchy of Resources.

I believe caching HTTP requests wouldn't be against the spec if you wanted to - but may lead to other issues. What if the device boots without RDE? What if it's RDE configuration changed while it was down and you've got a cached request to a physical function that isn't there anymore? What if the device randomly assigns PDR numbers and ResourceIDs every boot and the BMC needs to divine what the new target for the request is? What if it's just a week-old request, at which point do you decide it's expired?

Awesome news about OpenBMC picking up RDE and I'm looking forward to plugging my RDE device into it. Any tips on what (preferably cheap) box I can pick up that I can flash with some OpenBMC experimental builds once they're public?

Implementing it is the best occasion to introduce corrections, erratas and clarifications to the spec. 

Remember to code to specification. RDE is complex and you may find behaviors in devices in the field that aren't explicit in the spec - but aren't prohibited either. Those usually would follow the path of least resistance for a given vendor to implement while preserving spec compliance. Spec compliance still provides ample axis of freedom however, and I wouldn't be surprised if you'd find devices that are simultaneously not explicitly violating the spec and also have various irreconcilable nuances between each other. Whenever you see something that calls for a switch(VENDOR) kind of differentiation, that's a good sign this needs to be addressed in spec.

As for caching case, a paragraph or two about caching requests may make this clearer for future implementors. My recommendation would be to discourage, but not prohibit caching. Both an RDE device and BMC may make special beyond-the-spec provisions to enable caching for a select number of hand-picked cases, but in general, once a device drops off the bus, it ought to drop from the Redfish Resource tree.