This is not a TODO list, it contains ideas. Some can readily be added to the engine, some might not be that good of an idea.

Features

List of NEW things to add or minor tweaks. This does NOT contain major changes to existing code.

Easy

Easy to add features!

Show name of current test in engine window
Ability to attach idisposables to the engine (for disposing on shutdown)
Add lineSphere to linemanager3D
Extension method LimitLength for a vector, that clamps its length
Create mathhelper for getting a function through a point (linear, quadratic), through 3 points, through x = 0, a, 1 and given y values for these 3 x values.
Add a 3D text panel (simple tex texture + quad mesh). Add a billboard option (using per frame billboard matrix update)
Allow setting of screen resolution and size

Debuggertypeproxy attribute!
Alternatively allow pressing a button that compiles and attaches debugger in a single go.
Cleanup wizards tests, organize them in such a way that you can use them as documentation. They should show which is the latest code, which code works, and which code is deprecated, obsolete, or in need of refactoring, when doing this, some form of automated testing should be added (at least a measurement that shows howmuch code is still doing something)
Use an attribute to mark certain tests as documenting a feature, and automatically post them to the wiki.
use DSL to create AI behaviour trees?
Create algo that scales rendering quality with performance (using parameters: nb shadow maps, resolution of shadow maps, nb lights, view range, shader effects) Simply try all combinations for half a sec for some scenes to check ideal framerate?
Add windsor dependency injection to the construction of nunit test classes.

Contains ideas on how to improve or rewrite existing parts of the engine.

on commit, copy everything and compile it, with a clean, to check if the commit is ok!
Single file hotloading support in the engine, using redirection with postsharp
Compiling from the engine instead of vs, to allow for editing code during debugging! (disable the code lock on debug in vs, and then my theory is that when reloading new gameplay dlls, the new source files should immediately be correct!)
on hotload, it could also be possible to use a compile time step to add field intercepts to the newly compiled dll, which redirect to the old classes. This prevents data copying on hotload!. It might also be possible to attach to the .Net collection classes and also solve that problem.
Maybe simply replay all changes when hotloading??
If the hotloder knows which classes have changed, it could potentially guess which data of before the hotload to reuse. This would mean no more total data copy, only a small copy. If this guess is incorrect, the user can still reset the test.
Interface based hotloading: define interfaces, which are wrapped when the IoC dependency tree is build. These wrappers check the target assembly for changes (eg build), and reload the wrapped class. This is a fairly simple to implement mechanism to perform hotloading at a less granular level, making it useful for applying without changing the underlying system.

Create a engine that allows for running tests (no rendering etc)
use postsharp to apply profiling aspects to everything, but do a compile time check which uses the run-time performance data of the methods, to know how deep to add profile attributes. Add compilation of the gameplay dll by the engine itself. Every time it is recompiled, a better selection of profiled methods is created, which allows it detect hotspots while running.
Idea: intercept all methods in the gameplay module, allow pausing and breaking of execution! This effectively makes these classes like a scripting language. For behaviour trees, you could now add a tree visualizer of the tree, and break execution to debug the tree.
further think about decoupling gameplay code from the rendering thread. Find out how to seperately debug the gameplay code without breaking the rendering.

Unload assets which have not been used for a while. This is even more important for dynamically created mesh assets which are not used anymore. Maybe add a mechanism to indicate meshes are dynamic?
Encapsulate all the features of the editor window in a single class! Also add that when the window looses focus, it releases its cursor.

Describes ideas concerning coding style

Don't store data using classes from the outside (eg libraries or other architectural layers) (Eg don't use physical!!)
Also don't expose services that use these classes, since they can't be used anyways!
Does this simply mean: interfaces should not contain anything other than structs and interfaces?
it always seems to come back to TDD, when design problems occur. This leads to the mhgw design methodology. Note that the core of scalability is adding features without breaking other features. TDD provides a fool proof method of allowing scalability.
Use 'Refactor: ' prefix to indicate something should be refactored, so that refactoring can be done in larger batches
be sure to mock all parts of code that use user input as close to this input as possible, so that the program can be run without user input (for testing).

Ideas related to improved programming techniques. More general features relating to coding are also allowed

Very interesting http://docs.castleproject.org/Default.aspx?Page=DictionaryAdapter-Introduction&NS=Tools&AspxAutoDetectCookieSupport=1
interfaces are not meant to be defined first and then used by components to let them work together, but they are part of the contract exposed by components. This makes that there will be loads of double interfaces, which is not that much of a problem, since a mechanism can be created that connects the interfaces (fully, partially, or by renaming, by conversion,...). The goal of the 'planning' aspect of programming is then to limit the work in these conversion definitions. To simplify this, it is possible to 'plan' an interface which multiple components will require, and put this outside of the components and define it as a seperate interface. This simplifies thinking about subparts of the system, and one could see this interface as an interface that is part of the contract of the submodule! Now only intermodule linking is required. One can see that linking can be made hierarchial, which allows reducing the computation complexity to logarithmic.

Let me name this 'scoping of concepts'.

Show documents related to the currently editing files in visual studio.
Instead of mocking in code , mock with a gui
create a utility to quickly generate a adapter for an existing class in an external library. Eg: it should be possible to simply 'wrap' slimDX with generated classes. This is to be used when you wan't to remove a dependency from your code, but it still has some uses of this library left. You could then simply wrap it quickly, removing the reference but keeping the code intact.
Create something that automatically implements tests, using a set of predefined algorithms, combined with some logic solving.
Notice that linking components can be done Visually using a flowgraph!