Try-catch-finally error handling is definitely a great added feature. I also believe converting a lot of the stored procedure based operations converted to declarative statements (such as CREATE LOGIN, etc.) is also a plus.
T-SQL provides a work-around for inserting multiple rows into a table using a UNION ALL or UNION query so I don't see an ANSI equivalent as being that important. Is there an official ANSI syntax for inserting MULTIPLE rows using a VALUES clause?
Natural joins in my opinion are really not a good thing and can be left out all together. Relying on columns in different tables to be named similarly means a naming style which uses that convention must be implemented for columns in PK-FK relationships which is not always the case. Explicitly specifying the names of columns involved in a join (except CROSS JOINs) is much better practice for every query using a join in my opinion.
One issue that has irritated me since version 4.21 is the complete lack of internal code reviews for system stored procedures. The internal procedures contain the biggest hodge podge of coding styles, naming conventions, unnecessary cursors/temp tables, etc. With all of the variable declarations and some unnecessary cursor use, it's as if a C programmer (no offense to C programmers out there) wrote the SQL for a lot of the system procedures. Some use underscores in the core part of the name, some don't, etc. I would think for licenses that can now hit $20,000 per processor, MS could establish some consistent naming and style rules and have a senior development manager review each procedure for performance and adherance to the established conventions.
My final peeve deals with object-relational capabilites in SQL Server. As someone who writes almost all of their application logic in C# and not T-SQL, it's a real issue trying to map OO classes to relational data. This has been an issue for developers for years so I'm not really bringing up anything new. I realize that MS will be releasing ObjectSpaces as an O/R mapping tool to allow developers to build domain and business objects more naturally without having to incorporate something like DataSets (typed or untyped) into the mix. However, it seems that having SQL Server provide object-relational capabilities in addition to just pure relational capabilities would be something on the table. Do you know if this is something they are working on? Also do you know the quality of the object-relational capabilities provided by PostgreSQL or Oracle? I posted these questions a while back on the forums, but didn't really get any responses with any insight. Previous ORDBMS thread.