You got the "native" part all wrong and I guess that looking at it from your point of view it is understandable why you got it wrong. We would never implement a web technology framework utilizing a client technology as it simply does not work. What I meant by native is that it is natively integrated as an ASP.NET build provider which means that it is completely implemented using the ASP.NET best practices and at the end ASP.NET is doing the heavy lifting on the server.
That said we will allow usage of client side XAML which is kind of like the same way ASP.NET treats HTML tags which are not marked with runat server.
The idea is to provide the a web development interface to Visual WebGui, in-terms of the ability to change the application dynamically and work with markup code instead of pure object oriented approach. In fact it is basically providing developers with a way to develop Visual WebGui applications in a manner that is more close to developing an ASP.NET application. We could have taken the ASP.NET markup concepts but obviously Microsoft has moved on in-terms of their concept of a markup environment and instead of providing the old way of doing things we decided to implement the new way.
The big difference between ASP.NET markup and XAML, is that ASP.NET relays on known classes that can be used while XAML is a generic language that can apply to any object model and as such provides more flexibility to the developer in what can or cannot be done from the markup code.
Hope that provides a better picture on what we are aiming at and or considerations.