TableAdapters - A Critique

I have been a fan of Typed DataSets since the PDC Beta of .NET.  I’ve been asked to detail my recent criticism of Table Adapters in the .NET 2.0 Typed DataSets. Here are the points that I am most concerned with:

• TableAdapter designers are fragile. Editing the first query in a TableAdapter attempts to make modifications to other queries to keep them in sync.  This works the majority of the time with all text queries, but will lose changes occasionally.
• Choosing to “Refresh the Data Table” in the DataAdapter Wizard causes a SELECT statement to be put after the INSERT (and I think the UPDATE) statement(s).  If you change the SelectCommand, this statement isn’t changed.  Also, there is no way except for the wizard or manually editing the .xsd file to force this change to happen.
• While I understand that the purpose of the way that Typed DataSets are to be used are more for a RAD type of environment, I think that the TableAdapters do not work well with stored procedures.  Changing the resultsets inside a stored procedure seems to confuse the Table Adapter.
• One of the most common (and hopefully performant) suggestions I gave to users in 1.x was to use a DataAdapter to fill their DataSet by returning multiple resultsets. As Table Adapters work today, each table adapter opens and closes a connection (though this is mitigated by pooling) and returns a single resultset.  I would like to see a better story to the batch return of data.
• The way that TableAdapters put together their connection strings by stringing together parts of the namespace in the web.config (or similar file) is frustrating in that either code that needs connection strings, must either share the connection strings that the Typed DataSet generate or must keep two copies of the connection string.  I would like to see it where you can specify the connection string for a particular TableAdapter or DataSet to use a specific name in a .config setting.
• I should be able to create a DataAdapter as part of the Typed DataSet designer (though not specifically a TableAdapter issue).  If it’s a design surface, it should be able to handle DataAdapters for more complex scenarios.
• The ClearBeforeFill option is intriguing but making the default be clear the Data Table before filling further clouds one of the most intriguing features of DataSets: the ability to be a growing cache of data.  I make a case for this in my book. I think this is a technological fix to a training problem.

Anything I missed?