Udi replied to my post, I was going to answer in his blog but it was too long.
This is not about using DataSets. It's about knowing what happened with an entity.
Suppose you want to edit an 'Aggregated Entity', like an Order, with header and details. You want to do it in a multi-tier application. The application retrieves the order using a service, the user changes something in the header, deletes a line and adds another line. Now you want to save the changes.
First, you need to know what happened in the client. You need to know a line was added, another modified, etc. You could also need to know the previous values for optimistic concurrency checkings. You need a change tracking mechanism. You can use the DataSet or a custom one, but you need one.
Now, we need to send those changes to the server, together, because I want them executed in a single transaction. I cannot have a service called 'ModifyOrderCustomerInformation', another 'AddALineToOrder' and 'DeleteLineFromOrder'. I need an 'UpdateOrder' service. You can use a diffgram to do it, or you could build your own change-serialization mechanism.
So, I really don't see how you can build an application the way he suggests. It's very nice from the 'service' point of view, but it's very difficult from the client point of view. The only way I see is to map the UI to the service interface, so the user can 'Change Address' or 'Update Marital Status' as different operations in the UI layer, but I can't let the user 'Modify the Customer'. It's a lot of work, and I seriously doubt that the users will like it.
Additionally, you need change tracking even for web apps. If you want to 'edit an order' using an Aggregate, you need the whole Order, you need to have the Order somewhere (session/viewstate) while you edit it, and you need to know what happened. With the Entity Framework you will need to manage it manually, as David's post suggests.
Even if Udi is right, and that's the way applications should be built, I doubt most mere mortals in Earth will want to do it. It's too much work, just for not 'sending the changeset'.
David Simmons explained how the 'disconnected mode' works today in Entity Framework (and as far as I know, that's the way it will work in the Orcas release).
Basically, there is no disconnected mode. You can create a context and attach objects that you kept somewhere, telling the context if it was added/deleted/modified.
This basically means that if you plan to build a multi-tier application with ADO.NET Orcas in the middle tier, you will need to hack your own change tracking mechanism in the client, send the whole changeset, and apply it in the middle tier. From this point of view, it's a huge step backwards, as that's something we already have with DataSets today.