While WPF provides robust support for binding, the presence of hand-coded member names within XAML is still a bit stifling.

What would make things easier would be:

1. A stupid easy means of declaring a design-time data context. Yes, I can import the Blend designer namespace to do this, but doing this requires adding yet another namespace to already incredibly verbose XAML files, marking that namespace as ignorable, importing the namespace of the design-time object (even if that namespace is never used in the XAML), and instantiating the object. In many cases, the designer-mocked class won't compile, so I'm forced to add a parameterless constructor to my class just to support the designer
2. In WinForms, if I attached, say, a ComboBox to a binding source, the designer gave me a friendly dropdown in the ValueMember and DIsplayMember area that let me CHOOSE a property rather than typing it as the XAML/WPF designer forces me to do. Which means I have to go double-check my class to ensure that the text property I want is called Name instead of Description or somesuch.
3. Provide the option for designer warnings when I'm bound at design time to an object and one of my bindings is to a property that doesn't exist

With WP7 and MetroApps, all pushing towards XAML. I noticed these frameworks have standard styles for titles, headings, and other controls, but what I found cumbersome during coding, especially if you're just a text-editor user, is the ability to see what a particular text block style looks like and which ones are available to be chosen.

In office applications, there was conventionally a preview pane that's docked to the left or right oft the screen which lets you manage styles, this I believe is true in Expression Web as well.

It would be great if the tooling team on Visual Studio, could look into providing this feature.

I often find myself having an MSDN reference page opened to see what a particular WP7 textblock style encompasses (font weight, colour, font size) etc, and to be able to remember what the Resource key name is also difficult, if it's the tip of my fingers when coding my XAML, this would definitely benefit.

Furthermore this style preview pane could be extended to WPF and SL as well, the Style preview pane would be able to infer all your reference resource files and any other defined styles you may have, and be able to render a preview of it.

I think one of the most common failures of Windows Store apps certification is crash related to snap view. It is often caused by removing or renaming of XAML elements, which still preservs in the VisualStateManager.

For example this causes a runtime crash when backButton element does not exists:
<VisualStateManager.VisualStateGroups>

<!-- Visual states reflect the application's view state -->
<VisualStateGroup x:Name="ApplicationViewStates">
<VisualState x:Name="FullScreenLandscape"/>
<VisualState x:Name="Filled"/>

<!-- The entire page respects the narrower 100-pixel margin convention for portrait -->
<VisualState x:Name="FullScreenPortrait">
<Storyboard>
<ObjectAnimationUsingKeyFrames Storyboard.TargetName="backButton" Storyboard.TargetProperty="Style">
<DiscreteObjectKeyFrame KeyTime="0" Value="{StaticResource PortraitBackButtonStyle}"/>
</ObjectAnimationUsingKeyFrames>
</Storyboard>
</VisualState>

<!-- The back button and title have different styles when snapped -->
<VisualState x:Name="Snapped">
<Storyboard>
<ObjectAnimationUsingKeyFrames Storyboard.TargetName="backButton" Storyboard.TargetProperty="Style">
<DiscreteObjectKeyFrame KeyTime="0" Value="{StaticResource SnappedBackButtonStyle}"/>
</ObjectAnimationUsingKeyFrames>
</Storyboard>
</VisualState>
</VisualStateGroup>
</VisualStateManager.VisualStateGroups>

I think Visual Studio should check if elements names mentioned in Storyboard.TargetName really exists. If not, it should cause a compile time error. Runtime error is too late for this.

I have previously mentioned it here: http://social.msdn.microsoft.com/Forums/en-US/toolsforwinapps/thread/875c4985-64c7-4352-a4be-1d2913de75f7