b) Derived functions that can return compatible derived types
Last time I checked it did, which was a good surprise. I think your problem in your example is due to the parameter list, not the return type. So it's again related to a lack of overloading, not the inability to have overriden methods return different types.For (a), while it would clearly be nice, it isn't mandatory (it's usefull but not that much more than for any function, the constructor is not so special here).
BTW, overloading has close to nothing to do with OO. You can have it in non OOP languages, and (as in BlitzMax, but it's no the only one) you can have OOP languages without it.
The arguments for overloading are clear. Arguments against include the ambiguity problem (which one to call when more than one compatible overload is found). I would argue here that a solution might be to completly remove ambiguity by always disallowing for 2 overloads to have corresponding parameters (parameters at the same position in the parameter list) that are implicitely convertible from one the the other. The other alternative (chosing the 'best' overload when possible like in C++) would be too muech of a mess.
What lacks more is some acces restrictions at the function/method level. If the client 'MyType' should always call MyType.Create, there is currently no way to enforce it and prevent the direct call to the New AFAIK.