Great point, Lindsay. A few comments:
The logic for estimating dates is relatively easy, technically. Like you say, dates can be grabbed from siblings, spouses, parents, children etc.
We do this estimation in a few contexts. We do it with GEDCOM imports so that we're not importing a bunch of people born 400 years ago. And we have done it to Open up profiles born 300 years ago even though they don't have dates. We'll do the same thing with 200 year old profiles soon.
As you say, it would be great to have these estimations in other contexts, such as FindMatches results. Why match someone born in the 1600s with someone born in the 1900s, if it would be relatively easy to estimate the DOB of the person born in the 1600s based on their family members' dates? The system should be smart enough to do this.
Here's what I can't figure out.
It can't be done on the fly because that would be too slow and eat up too many server resources. If before we showed any matches we checked all the dates of all the family members of all potential matches, FindMatches would be very slow. It's already a bit slow.
One way around this would be to do FindMatches offline. Instead of showing you results right away, we could build a report that night and show you better results the next day.
Another way around this would be to store estimated dates somehow. Instead of calculating them on the fly, calculate them periodically at night and store them in the database. Then it's easier and faster to access them during searches.
A complication is the updating of these estimated dates. They could become out of date, no pun intended, when someone edits family members' dates.
And UI wise, would these be stored in the normal date of birth and date of death fields, maybe with a new certainty status indicator?
