I actually agree with you, I wrote the post not to work on it, but give context and inspire the giants gmail, microsoft and others to do something about it.

Speaking in terms of higher level of usage of language, meeting invites are only one kind of coordination in language. You make a request for a meeting, the other has a chance to Accept, Decline or Counter Offer the meeting.

Coordination is a major use case of email. Whenever you ask someone to do something, or in another words say send you something - language wise you are making a request - its the same construct as that of a meeting - the action is different.

Meeting requests are the one type of request which has a natural time component. "Find me some headphones" doesn't have an inherent time component, it has a task completion goal. So, it doesn't make sense for it to auto-expire based on time. Dealing with closing/deleting email based on these fuzzy task completion goals cannot currently be automated, and you'd never want to delete the record of completed tasks, either.

For more complex transactional issues where some parties may be using email, there's ticketing/CRM. Once an issue is resolved, you close the ticket, which may log somewhere else. Generally these systems are more one-sided, where an individual interacts with an organization, and there isn't always much visibility into the ticketing state from the outside.

Nice find for sure. I think the issue with outside server technology is adoption by both sender / receiver - the main hypothesis is based on sync time management between both.

Like regular verbal communication (instead of messaging) happens over same time. For us thats like water to fish. Implementing a time server function to email systems would create a sync'ed communication system.

The problem with Client side time management is you cannot sync time across the sender and receiver. Server side is where it would produce the max productivity.