Yes, I get that.
This particular “ASSO” GEDCOM tag support evolution could implement an Event associations immediately. But not Family Associations. Got that.
My point is uses the new 7.0 tags (like Family Associations) as an example of managing data that does not fit in the Gramps data model cleanly. This includes 5.5.1 tags and 3rd party _custom tags.
The current approach to storing unrecognized GEDCOM import data was designed before Attributes were extended to so many primary objects.
That importer opted to store that data in “GEDCOM import” Note type, attached to the parent object. But the error handler wraps the unrecognized tag data in human readable messages and formatting. Rendering it unparsable by another GEDCOM tool.
Take the Royal92.ged ( classic 1992 sample genealogy data by Denis R. Reid 1937-1998) that has a nonstandard PAF 2.2 COMM (comment) tag
This fails to parse and is transcribed to a Note.
But, if that tag structure was stored in an attribute (with an Attribute type that reflected the source being a GEDCOM and parent tag or possibly the Source being the generated from the HEAD data and citing a vol/page of filepath filename line number; or maybe prepends a HEAD data to ID the Gramps Importer and parent objects of the original GEDCOM), then we’d be able to go back and post process. And be able to test experimental code to parse that dialect of GEDCOM… maybe rolling it into a dialect handling enhancement.
)