Have you had a chance to play yet ?

Many folks have noted that a lot of the Visual Studio elements that have been present within BizTalk to support the development experience are no longer...quite so BizTalk specific!  BizTalk projects now build upon C# projects, and thus a lot of the differences that you used to see in navigating property pages, compilation settings and build mechanics are now gone.  This is a very good thing - it allows you to leverage skills you already have on your team.

MSBuild support is now first class.  Everyone who went through the trouble to install (and invoke) DevEnv.exe on their build server in order to build BizTalk projects will be glad to know that this is no longer required.  (Builds can be ever so much faster when you aren't relying DevEnv...)

Because of the close relationship with C# projects, you can now have C# artifacts directly in your BizTalk projects.  Many people have noted that when you "Add new item...", C# classes aren't offered as an option.  The product group has explained that this is because currently, the designers (such as the Orchestration designer) are unable to provide intellisense for types that are within the same assembly.  So, you are required to use "Add existing item...".

(This sort of reminds me of the interaction between pipelines and schemas - the former require fullly qualified assembly information at run time, which they won't get if you combine these two artifacts in the same assembly.)

If this limitation persists, will the feature get used?  I tend to think so.  There are often cases where the smart thing to do in an orchestration is to delegate to a component...but the work you do in that component is, at times, so specific to the orchestration that it makes sense for them to be co-located for deployment and organizational purposes.  What do you think ?

The support for unit testing is extremely welcome - check it out.  Debugging maps is great as well, but I'm now (often) partial to the external XSLT approach these days.