I know that this is one topic that has raised interest in minds of many database designers. The next generation of SQL Server is full of promises. With the release of Yukon we will be able to do amazing things. What I would try to do here is to enlist some of the public information published on the internet. There are tons of links that come up if you were to search for "Yukon" on any search engine. We will try to highlight some interesting features available from the net. You can also visit the resources page to get a list of some of the links.

From eweek.com

• As per Campbell (Microsoft product unit manager for the SQL Server Engine), Microsoft is also working on making its XML features "deeper," he said. The company released an XML update this fall, focusing on making the common language runtime and the application frameworks of .NET run inside the database itself. That was a huge shift from the past, Mangione said. All further work on XML will continue to be done in-house—it would be too difficult for Microsoft to integrate with another vendor's native XML database, he said. XML databases alone are a successful niche product.
• But Web services are a foundational technology in the new product. "Web services plumb directly in Yukon," Campbell said. "Yukon can directly host Web services and will generate standard WSDL [Web Services Description Language] for binding in clients."
•  "We're making a ton of investments in developer productivity," Campbell said, noting that developers can write "stored procedures in any CLR language." Another new feature of Yukon is its integration with the Common Language Runtime (CLR), which supports development in more than 25 languages.
• According to Tom Rizoo(Microsoft Group Product Manager), We upped the level of XML support in Yukon through a number of things. In 2000 we had XML support but … it was shredding. [Shredding is the parsing of XML tag components into corresponding relational table columns.]  In Yukon the key thing is we have an XML type. Like you have STRING and NUMBERS and all that inside the database, now you can declare [with the native data type] XML. Although we had XML support in 2000, and many leveraged it and were happy with it, now we have native support.
• Our goal is that Yukon will at least meet the same performance as SQL Server 2000, but we're hoping it exceeds it. That's in all aspects, not only in terms of what SQL Server 2000 has, but some new capabilities. For example, writing code in .Net should be the same as writing code in the T-SQL environment.
• .Net code today doesn't run within SQL Server. It runs separate, outside the database. In Yukon we've put it into the database. Our plan is that T-SQL and .Net technologies will run at the same speed. The reason we're putting .Net inside the database is now customers can write SQL Server business logic inside the database using any .Net language. For example, you can use C# or Visual Basic. We're also talking with Fujitsu, who builds Cobol .Net.
• Building on SQL Server 7.0 and SQL Server 2000, SQL Server "Yukon" will deliver an end-to-end business intelligence platform with integrated analytics including online analytical processing (OLAP); data mining; extract, transformation, and load (ETL) tools; data warehousing; and reporting functionality. This comprehensive, integrated approach will enable organizations to seamlessly build and deploy robust business intelligence applications while controlling costs.
• Developers will be able to utilize one development tool for Transact-SQL, XML, and Multidimensional Expression (MDX). Integration with the Visual Studio® development environment will provide more efficient development and debugging of line of business and business intelligence applications. SQL Server “Yukon” will also include robust enhancements to the Transact-SQL language.
• Enhanced high availability technologies, additional backup and restore capabilities, replication enhancements, and "secure by default" settings will help enterprises to provide users with secure, consistent access to enterprise applications.

From microsoft-watch.com

• According to Campbell (Microsoft product unit manager for the SQL Server Engine),  Yukon characterized as a "fourth generation" database that is optimized to provide "autonomous computing." Microsoft executives have used the autonomous computing label to describe interactions between computers that don't trust each other.
• Campbell highlighted Yukon's Common Language Runtime (CLR) integration, built-in Web services support, new messaging features, support for new datatypes and general scalability and availability advances.
• Yukon won't be an XML database, but will rather integrate support for XML data types into the relational SQL Server database.
• Yukon will be tightly integrated with Microsoft's Visual Studio .Net development suite, Campbell said. That way, database programmers will have access to Visual Studio's authoring, debugging, profiling and IntelliSense capabilities.

From accessvbsqladvisor.com

• You will no longer be required to use Transact-SQL to write SQL Server stored procedures, triggers, and user-defined functions. You'll be able to create these objects using any of the .NET languages -- VB.NET, C#, C++, or even COBOL.NET -- and compile them into .NET assemblies.
• One important benefit of relying on the .NET Common Language Runtime is that it can verify that all code hosted by SQL Server won't cause any memory usage errors that would bring down the server. In addition, SQL Server will benefit from the CLR's robust support for versioning and security.
• Data access in Yukon will be based on a new set of managed interfaces in ADO.NET. This new set of ADO.NET classes will be grouped within a namespace that is currently being called System.Data.SqlServer, and these classes will interact directly with SQL Server's internal query processing mechanisms.
• SQL Server will also leverage the Common Language Runtime's code access security model. By default, code doesn't have any permissions to create a graphical user interface, create threads, access the file system, or call unmanaged code. The only permissions implemented are those granted for in-process SQL Server data access.
• Altering assemblies will not be allowed to invalidate persistent data or indexes. For example, suppose you have an indexed, computed column that relies on a .NET function to perform the computation. Changing or dropping this function would invalidate any data stored in that index. Dependencies are tracked, and you can't drop an assembly if dependencies exist.
• In Yukon, you can encapsulate your middle-tier logic within server-side components and still have all the advantages of running as compiled machine code, not interpreted Transact-SQL. This won't make much of a difference for code that's primarily performing data access; the goal for Microsoft is that CLR data access code will execute as fast as the equivalent code written in Transact-SQL.
• Relying on .NET code won't hamper the scalability of your SQL Server database operations. Yukon's ability to handle a given number of concurrent users with a given set of hardware resources will be as good as (or better) than that of SQL Server 2000.
• If you already have a significant investment in existing Transact-SQL code, there is no need to worry. Transact-SQL will continue to be fully supported. Transact-SQL itself will be enhanced to support new functionality not currently available.
• A new developer tool called the SQL Server Workbench will support deployment of assemblies to multiple servers and will contain a powerful subset of Visual Studio.NET capabilities for code management. It's too early to tell what the SQL Server Workbench will actually look like, but it will most likely resemble the user interface currently available in Visual Studio.NET.

From itwriting.com

• According to Euan Garden (Microsoft's Product Unit Manager for SQL Server Tools), SQL CLR (Common Language Runtime) is significant, which is the ability to host CLR-based languages inside SQL Server. It gives developers language choice and architectural choice. We've tried to make it as seamless as possible to write code for the middle tier, move it into the database, and move it back out again.
• The investments we're making in business intelligence are huge. Reporting services are coming, and there'll be a version for SQL 2000 as well as a version for Yukon.
• I think the XML-based technologies are huge as well. The new XML data type, the new XQuery-based technologies. And then there's the bread and butter, the database engineering, more scalability, more reliability, partitioning, faster backups, more reliable backups.
• The CLR programming environment allows us to do stored procedures, functions, triggers, user defined data types, and user defined aggregates. It's not just stored procedures.
• When asked about the CLR languages support, he said we're committed to VB.Net, C# and managed C++ in the initial release.

From msdn.microsoft.com

• According to Eric Brown (Poduct Manager for SQL Server), The integration of SQL Server "Yukon" with the .NET Framework represents the delivery of a more symmetrical programming model between the middle and database tiers. Writing database logic in either Transact SQL (T-SQL) or any .NET-compliant language means greater productivity for developers.
• XML integration is as important as the .NET Framework integration. SQL Server "Yukon" will ship with a full-fledged XML data type that will support XSD for schema validation.
• SQL Server "Yukon" has just entered Beta 1. We will do more betas as we get feedback from customers. Our current goal is to have a public beta in the first half of 2004.

Note: All the views and contents are from the various sites outlined above. We have consolidated some information from the same.