It strikes me that 'compatiable' or 'clean' gedcoms ought to be a high priority in FH software, I must admit I had just taken it for granted when I shoped round for a PAF replacement, we live and learn!
There are at least two major problems in this area. One problem is that the GEDCOM standard is very fuzzy. Even if doing their very best to comply with the GEDCOM standard, two different genealogy software packages could easily interpret many aspects of the standard in different ways. The other problem is that the GEDCOM standard is very confining. If a genealogy software package limited itself only to those features that can be readily exported and imported via GEDCOM, they would be very limited in the features they support. Indeed, they would probably look almost exactly like PAF. Finally, these two problems aggravate each other. If a software package does implement innovative features and does attempt to adapt the data associated with those features to GEDCOM, the way the package adapts those features to GEDCOM is not likely to be the same as the way a different package that implements the same features might adapt those features to GEDCOM.
I've understood these issues pretty well for years, but they have been reinforced for me by observing the recent struggles by TMG refugees trying to find a new genealogy software home. TMG is the most feature rich genealogy software that has been on the market, and it deviates more from the GEDCOM standard than any other genealogy software. TMG refugees are struggling to find another genealogy software package that meets their research needs moving forward. Almost equally important, they are struggling to find another genealogy software package that can receive their TMG data without significant loss. RM and several of its competitors have addressed the second issue by providing a direct import of data from a TMG database. But it's tricky to import some of the TMG data when said data depends on functionality that doesn't exist in the software package doing the import.
As a result, I'm reconsidering whether or not to use certain RM features, and if I use them - exactly how might I use them. For example, I love RM's Place Detail feature and I use it extensively. But the problem with GEDCOM export of Place Details is making me consider whether I wish to use it or not. For example, I purchased a package called Charting Companion because it can produce some reports that are not supported by RM. I found out about it because it was mentioned on the RM Web site, and there is even a Webcast on the RM Website about using Charting Companion with RM. But Charting Companion does not support RM's Place Details. Or more correctly, it didn't support RM's Place Details, I requested of Charting Companion that they add Place Detail support, and they did. But they implemented it incorrectly.
This is not RM's problem, and I certainly do not expect RM to fix a problem in Charting Companion even though RM more or less provided free advertizing for Charting Companion. But it is my problem, and I need to deal with it. My experience with Place Details and Charting Companion alone is probably not enough to make me quit using RM's Place Details. But how many more such Place Details problems are out there? Suppose I started using RM to exchange data with Family Search (I don't right now). What would happen with Place Details? Suppose I started using RM to exchange data with some other site or with some other genealogy software package. What would happen with Place Details? It is very worrisome. But not being able to use Place Details is worrisome as well.