You said: "In light of the GEDCOM standard for descriptions being out of date and inadequate here - I would thought that the simple solution was for all developers to (a) simply not limit descriptions to stupid, arbitrary limits of 100 etc and/or (
Do what RM have done and import other program data natively."
Unfortunately your assessment here is wrong. But not due to anything other than not understanding the GEDCOM standard.
GEDCOM "descriptions" are NOT out of date, and probably not inadequate, in any way.
1) In GEDCOM a "FACT" has no such field called "description" so calling them or inferring that they are a description is initially wrong.
2) The location where FTM places the data from the "description" data entry field in the GEDCOM is incorrect. This location has specific defined data requirements, which if you read the documentation rarely exceeds or needs to exceed 100 characters
3) Only 3 of these defined data elements have a definition that approaches a "description"
a. DSCR tag known as "Physical Description" It is the only tag that allows for an unlimited value.
b. EDUC tag known as "scholastic achievement" 248 characters long. Defined as "A description of a scholastic or educational achievement or pursuit"
c. PROP tag know as "Possessions" 248 characters long, Defined as: "A list of possessions (real estate or other property) belonging to this individual."
4) Having looked at the data that may people place in the "description" field, I can see that GEDCOM has other tags (or fields) that this data can more appropriately be placed.
a. Names and ages of other people found in a Census should be placed in the "Notes" portion of the "Census Event" or better in the TEXT portion of the Source_Citation for that Event.
b. Additional documentation of a location of any event/fact such as: "The green house on the hill", or "they only lived here three months" (in a RESI fact) would be much better in the Place_Structure i.e. EVENT.PLAC.NOTE tag in the GEDCOM.
c. I could write an entire book on how to use the GEDCOM correctly. Yes it has its problems, no argument, but they are not what you have outlined here.
5) The DEAT tag has only one allowed value in the GEDCOM a 'Y' that indicates the individual is in fact "Dead". The 'Y' is only valid if and only if no other data is associated with the DEAT tag, such as a place or a date. If you have other information about a DEATh it probably has a place in the GEDCOM, if someone in the software world was smart enough to put it there.
6) If you have a DEAT and you know the "Cause of the Death" you should have a field available to enter "Cause" for that matter any event or fact that makes sense to have a "Cause" should have a data entry field for that cause.
7) If the person was married as a Catholic, Protestant, Jew or Muslim. This value does not go in a "description" field it goes in the RELI tag aka Religious_Affiliation a subtag of the MARRiage tag.
8) As noted above ADDR is a place to enter an address in the form of a mailing label. It is not appropriate to put a "description" or "place detail" here unless it is in the form of a multi-line address label. This would be great in a RESIdence tag.
9) Events and facts have a TYPE tag subordinate to the primary FACT/EVEN tag this tag is used to refine the superior tag. For instance A stillborn baby could have BIRT tag with a TYPE subtag of "stillborn" no need to put this data in a "Birth Description" field.
I hope this long introduction to GEDCOM use dispels the incorrect statement that the description is out of date or inadequate. And it also helps to dispell the notion that GEDCOM does not satify many of the needs of a genealogist. It is NOT GEDCOM, it is the programs and the programmers that don't know anything about GEDCOM and users who wrongly and unknowingly assume incorrect statements about GEDCOM that need education.
Again.... GEDCOM is not perfect, it has many shortcomings, but "description" is not one of them.