The idea of objects.
Vista has the contacts folder; which is nice. If you're using Windows Mail. Use anything else and that folder stays empty. Now if there was a contact object in a file system everyone shared then that folder would be populated.
Now I realise when I type in a contact name WDS does pull it out eventually; but there's part of me that hankers after a common object store.
But boy was promoting objects to WinFS and back to the file system painful.
Who gets to define the schema for a "contact"? How about a "document"?
Once you start thinking in those terms, you realize quite quickly that the idea of abstract "objects" can quickly become unworkable. That's because Outlook's idea of what belongs in a contact object might be very different from Windows Mail's idea, which might
be very different from Thunderbird's idea.
Here's a really
simple example: To Outlook, an email address is a multivalued string property which lists all the possible email addresses for a particular recipient (there could be a dozen or so of them depending on the topology of your network).
To Windows Mail, an email address would be just an SMPT address. To the email system I wrote back in high school, it's a RSTS-E account name ([<octal value>,<octal value>], to something else, it might be something totally different, with a totally different
Now consider what happens when you use a contact in Outlook that was created by my high school email program?. Outlook doesn't know how to send email to this contact, it doesn't even know how to interpret the address.
Can you guarantee that all clients of this object store all handle these cases properly?
This is just one small example of the kinds of interoperability problems you can get - this one is probably solvable, but there are others that aren't.