Here is a checklist of things which could be added to the framework to extend its functionality (some of these have already been implemented in the framework):

1. The most obvious problem with the current state of the framework is that it does not have keyboard and mouse controls. What is needed is an input manager class which takes in key and mouse inputs and fires appropriate events. Key events are very simple to accommodate, since we already capture key events from within the .Net forms. Depending on your application, you need to either fully capture and hide the mouse (allowing for a mouse look mode, like most games provide), or allow the mouse to go in and out of the window, and capture mouse clicks and translate them into 3D rays within the scene. This is a non-trivial task, and would require a hefty amount of code to implement. 
2. With the addition of keyboard and mouse input, you probably dont want to shut down whenever the escape key is pressed. Instead there needs to be a way to explicitly shut down the framework by ending the render loop. 
3. We currently only have added code for a single texture per material. Some complex materials have multiple textures. To fix this, the textures which are added to the objects Textures list should be a sequence type instead of a single value. 
4. The Camera class could use some work. I had meant to implement cameras using the SceneObject class (that is, inheriting from PositionableObject and RotatableObject), and providing the LookAt method as an extra method in the Camera class itself (though the LookAt would be a one-time deal, rotating to that direction oncethen leaving the rotation alone even if the Camera moved). 
5. There is currently no support for animation within the framework. This is clearly a severe limitation. At the time of writing this tutorial I did not have a mesh which contained animation, so I cut out the feature. 
6. There is often more than one copy of a mesh in a scene at any given time. As such, textures (that is, the physical image files) are often shared between multiple objects in the scene as well. To optimize this, a class would need to be implemented which manages the creation of meshes in the scene, allowing you to have multiple scene objects sharing a single Direct3D.Mesh and/or Direct3D.Texture. 
7. Many modern graphics applications use pixel and vertex shaders to add effects to meshes. If you make use of HLSL in your programs you will probably want to add this capability to your application. There is a Managed DirectX 1.0 sample in the DirectX SDK which shows how to add HLSL to a C# application. Use this as a basic guide to implement this change. 
8. Popping up a dialog box stating that a mesh or texture failed to load is not that useful in an application. A better system would be to parse a file which contains a list of resource directories. The system would walk each of these directories finding meshes and textures and add their locations to a dictionary (keyed on their filename without the path). Then, when a user requests to load a mesh or texture from file, look up the exact location in the dictionary (detecting if the file does not exist), and load it directly from that location. This would provide much better error handling, and simplify the loading of meshes (as the user would not have to specify a path). 
9. Most, if not all, games need some kind of user interface for displaying text or obtaining user input. The DirectX SDK comes with an example system which implements some basic widgets in C# (the CustomUI sample). If your application needs this functionality, that sample code is probably a good place to start. 

There are, of course, many other things you could add to the framework, but these are a few of the major features which it is currently lacking.

