A few random observations about SPContentType…

.Fields — This isn’t a complete collection of fields as it might be on SPList.  It’s just the fields that are directly added to the content type.

.Parent — This won’t return you a null if there are no parents to this content type.  Instead it keeps returning you the same content type.  So rather than doing what you would normally do — SPContentType.Parent == null — to test to see if you’re at the top content type, you must check SPContentType == SPContentType.Parent.  (or add .Id to each of these to make sure that you’re getting an equality comparison rather than a reference comparison.)

You may notice that some of the core fields for SharePoint items aren’t represented anywhere in the hierarchy (Author, Editor, Created, and Modified were the ones I noticed).

A final note is that even if a content type is activated in a site collection you may not be able to get to it from the SPWeb object of the current web site, so you get to walk the tree up to the root site in the site collection and pickup the reference from there.  Of course, you don’t want to add it to the current SPWeb object because you’ll get an error about a duplicate object.  (Apparently it exists, you just can’t retreive it.)