Does your question boil down to whether it's the importing program or the exporter who should be responsible for making the data compatible? My answer to that -- I suspect that we're in agreement -- is both. But I'm not holding my breath.
Yes Robert, I suppose it does boil down to whether RM is faithful to Gedcom in its export or whether the recipient program is lacking in its import routine and what to do with those extensions.
ADDR being a subset of any Place is exported logically within the fact as more detail within the Place, if the recipient program does something different with that tag due to it being lacking then I would say the problem lies there. I am no expert on Gedcom but on the face of it I would say that many other programs out there do not yet have the facility to include Place Details. It's been a while since I done any testing but I know FTM 2014 puts the Place Details in the description field and therefore in is not unique and cannot support Media, Geocoding and Notes as a standalone component.
I can't find it but I do remember RM backing away from webtags on Place Details as they could not be supported within Gedcom, I applaud this decision rather than stepping out on a completely proprietary route. I choose not to share Place Details with Ancestry as I believe they reduce the accuracy of matches by convoluting the Place text further rather than making it more concise and understandable for matches, Rootsmagic supports this perfectly for me.
The old arguments are that RM should facilitate the prefixing of Place Details to the Place on Gedcom output so other programs can import a single Place component, also that the option of returning Shared Facts to individual facts should be facilitated for the same reasons, I believe Legacy have introduced Shared Facts but have no idea how they fit within Gedcom.
So I suppose my question is whether Rootsmagic should invest time in providing options to export gedcom in different versions so competitor software can understand? or should the competitor software be working to import Place Details and Shared events providing Rootsmagic are adhering to the Gedcom standard, I would believe the later.
I do need someone well up on the Gedcom standard to comment on this but the output for Place Details seems perfectly logical to me at present.
Some facts ("occupation" is a particular offender, although that may be because of my own idiosyncratic entry techniques) require a lot of massaging after an RM7 --> FH6 import.
Personal entry styles is something no software company can do much about except, I would argue, understand and overcome the reasons for such personal systems. Alternate Name overcame all those personal entry techniques for missing names yet people still use them. I believe the remaining reason for that instance is wanting a place holder in reports where a name field is blank, this is something RM could easily overcome.