Tom has specifically asked for feedback on the design changes. Please let him know your ideas, feelings and bugs. Either use directx@microsoft.com or contact him via his blog.

I've not had much time to dig into the new Managed DirectX assemblies yet, but I figured running a quick WinDiff on the new samples would give a small idea of what is inside.

1. Caps becomes Capabilities - following .Net guidelines and using whole words.
2. ResourceType.Textures (enum) becomes ResourceType.Texture - also following .net guidelines and not using plurals for enums
3. GraphicsStream becomes GraphicsBuffer - seems more consistent with calls like LockVertexBuffer, but I'm not sure of the rest of the implications of this one.
4. ComputeBoundingSphere now returns a BoundingSphere containing the center and radius - nice, I never liked the whole return parameter thing in that call
5. TextHelper.DrawTextLine (framework call) becomes .DrawStringLine - not sure I like this one. I don't see much value difference between the 2 names. We already have a TextHelper so the method doesn't really need the String/Text/Line. TextHelper.Draw(string) should be sufficient here.
6. Mesh.FromFile(path, flags, device) becomes new Mesh(device, path, flags) - I like this too becuase it feels much more OO. I think I've read something about this pattern in the guidelines (but i don't have them memorized!)
7. Mesh.Clone(..., device) becomes Mesh.Clone(device, ....) - the whole device parameter is something we have to live with. I suspect consistency is the key here. I know a lot of APIs use it as the first parameter, so brave breaking change to make them all consistent.

8. int[] adj = new int[m.NumberFaces * 3];
   m.GenerateAdjacency(1e-6f, adj);
   

   becomes

   Microsoft.DirectX.Generic.GraphicsBuffer<int> adj = new Microsoft.DirectX.Generic.GraphicsBuffer<int>(m.NumberFaces * 3);
   m.GenerateAdjacency(1e-6f, adj);
   

   Strong typing, using generics, of the buffers to the mesh functions rather than arbitrary arrays.
9. Vector3[.Cross becomes .CrossProduct, .Dot becomes .DotProduct, LengthSq becomes .LengthSquared] - I bet there will be some complaints here, but again its correct based on the .Net guidelines methods should be properly spelled out. Stick to your guns on this Tom and Microsoft.
10. Matrix.PerspectiveFovLH becomes .PerspectiveFieldOfViewLeftHanded - OK this follows the rules and ends up a bit too long even for me. Personally I think its the wrong name anyway. I would think this should be replaced with Matrix.Projection since that is what it is creating and what is on the LHS of the assignment 99.9% of the time.
11. New namespace: Microsoft.DirectX.CustomVertex
12. new VertexBuffer(typeof(CustomVertex.PositionOnly), ...) becomes VertexBuffer.CreateGeneric<PositionOnly>(....) - I think I like where this is going but a method called CreateGeneric seems a little to much based on the implementation to me. How about new VertexBuffer<PositionOnly>(...)
13. CustomVertex.PositionOnly[] becomes GraphicsBuffer<PositionOnly> - seems plain enough
14. vertices[0].x=... becomes vertices[0]=new PositionOnly(x,y,z) - also seems simple. I assume you can still get to the .x, .y, .z if you need them.
15. new FrameworkMesh(..., path) now automatically uses FindMediaFile on the path parameter - sensible change.
16. FX enum becomes EffectFlags
17. CubeTexture.UnlockRectangle becomes .Unlock - I've had little to do with this API but .Lock is used elsewhere in the API so this is presumably more consistency.

Though a lot of these are breaking changes, my personal opinion is that they are for the best and most of them are simple cut and paste. The refactoring in VS2005 may even take care of some of them. One of my issues with Managed DirectX is that it has not felt like it is '.Net like' and these changes are in that general direction. I'm all for bending the .Net rules when performance is important, but .Net developers have got used to the consistency that comes with the CLR and its guidelines.