Thanks for your comments. Allow me to address some of your points:
There is a GEDCOM format. Data is read into the proper field in the gedcom match process, so I fail to see how that is a problem. If the data is read and put into the proper fields, can't it be matched? I don't envy the programmers trying to deal with the international issues - but if they can't deal with them, then maybe WikiTree shouldn't be international.
As to dates - again - the dates in my gedcom appear to be formatted OK. Further, if dates are formatted differently, can't a simple parse format them to the WikiTree standard. If no has done that, I would be willing to try!
As to names, I understand that in some cases phonetic variations need to be considered.and names can vary, no doubt about it. (My name could be Jim, Jimmy, Jimmie, James, James Raymond) But there should be more than a first name (or last name) match before a suggestion is made! And I think there is - I just think it needs to be improved!
You say that if a birth date is known, how can we not know the birth place. Birth dates are often caluclated based on census data, which almost never tells more than the state of birth, if at all. But is that to the point? If we have John Doe born 1/1/1930 is there any reason to suggest a match to Jane Doe born 1/1/1935? (I am making up this example - but the point is, should a mtach be suggested if there isn't some correlation between the name and other data present in the GEDCOM file?)
Your suggestion about limiting the file size of a GEDCOM import is good, but of course it doesn't solve the problems. Nevertheless, could a warning be posted on the GEDCOM import page to keep a GEDCOM file size small until the matching process has been improved? (If there is one, I certainly didn't see it before importing my file.) Family Tree Maker has often cited trees with many thousands of individuals..How could these people ever manage to import their data into WikiTree?