I am somewhat confused by your post. A single resource is not a "Document". It is true that we are using the definition of document as broad as http uses, so a single resource could be a document. However the expectation is that one would really only need a DocumentReference if one has something more self-contained, and something that has more of the document characteristics as defined by Structured Documents WG, and expressed in FHIR definition of Document http://build.fhir.org/documents.html. I also cover it a bit on my blog https://healthcaresecprivacy.blogspot.com/2011/10/critical-aspects-of-documents-vs.html
I have heard of people trying to publish individual FHIR resources using XDS. That is, they already have XDS/XCA infrastructure in place that can handle the discovery and routing. So rather than create new infrastructure based on http/REST, they will just put FHIR Resources into XDS. I suspect they have only a few resource types they would do this with.
I like your proposal for FormatCode when the 'document' is a FHIR resource. I see absolutely no reason not to use the method you present for formatCode. It is perfectly acceptable. In fact it is quite elegant. If someone has profiled that resource then it could be the URI of their profile. The unfortunate problem is that the metadata element is a code so needs an codeSystem, so that also must be filled in. I presume one could just use the root of the FHIR spec for that?
The point you make that the IHE specification says "should" be a URN... this is just a should, so no problem. The IHE specification was trying to get organizations that were inventing formatCodes to invent them in a way that would be controlled and discoverable.