Annoyances in the .Net Framework

This post is 100% whine.  It's where I get to complain about how parts of the .Net Framework are put together.  I don't intend to be constructive.

Statics

Why are System.IO.File & System.IO.Directory static classes?  They should be instance classes that do what FileInfo and DirectoryInfo do today.  I write static classes in my code to make up for holes someone else's library.  NDP is the end of that chain.

The Path class is nasty, too.  There's no PathInfo or some such.  There's no FileInfo.GetExtension(), so I get to write junk like “Path.GetExtensions (fileInfo.FullName)“;

Weak types

Why does is System.Environment.CurrentDirectory a string, instead of a DirectoryInfo?

Why does RegistryKey.SetValue take 'object value'?  What happens when you pass in, say, a System.Console?  One improvement would be to make overloads for each supported type (there are only 6).  SetDWordValue (int) seems much more sane.  Let's keep going: create a RegistryKeyValue type, and let it expose value-specific operations.  If you derive it to each of the support types, you can use nice OO constructs like:
     if (myRegistryValue is RegistryKeyValue.DWord)

Namespace arrangements

Why is Process in System.Diagnostics?  Does this make sense to anyone?

Lack of class nesting

Look in System.Windows.Forms.  See MessageBox, MessageBoxButtons, MessageBoxDefaultButton, MessageBoxIcon, MessageBoxOptions.  Can we please use nested classes, instead?  Then you would write MessageBox.Buttons, etc.  It makes your intellisense list shorter & quicker to navigate.

ConsoleColor should be Console.Color, too.  (new in Whidbey)

Same with Registry / RegistryHive / RegistryKey

Edit: moan about Sytem.IO.Path