There is a more efficient way to do content type IDS than we have done in the past: http://msdn2.microsoft.com/en-us/library/aa543822.aspx
Say we wanted to inherit from "Page", our content type used to look something this (I've split up the lines so it will display properly):
0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF5
Meaning, inherit from "Page" (the red part), include a delimiter (00), and then append a GUID.
If we then wanted to extend this content type, we would do this:
0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF500DFA39D91C06D48BDBC415E7CE80A95CD
And so on... You can imagine how hairy-scary the ContentTypeIDs can get if you wanted your inheritance to go a few levels deep.
As per the article, there is a more efficient way; the second ContentTypeID above could become:
0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF501
Where the tail 01 is the extended content type. Thus, we could have:
0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF501
0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF502
etc.
And then to extend from either of these:
0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF50101
0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF50102
0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900
188024C0FF7F45CFB85EBB43980DACF50201
etc.
IMO, this makes the ContentTypeIDs much easier to work with (and read), and we run less risk of running into URL length issues within SharePoint.
PS. The GUIDs used in the above examples have been changed to protect the coder. Any resemblance to any existing ContentTypeIDs are purely coincidental.