I see your frustration and I am really sorry that our latest changes are the major cause. I will try to provide some further details hoping to illustrate our point of view and help you with the migration odyssey.
A lot of customers were unhappy with our initial calendar design and we had to do something about that. The most important things that we had to fix were the awkward VisualSetting objects and the broken support for empty values. The visual settings were a bad case of the NIH syndrome
that were very hard for people to use. People could not configure their control without getting help from our support officers and that was very unproductive both for us and for customers. That is why we did the conscious decision of breaking backwards compatibility and moving to native ASP.NET Style objects to implement control styling. We realized that this may be hard for existing customers, but we believed we did the right thing as the control is much more usable now.
The empty values support was another pain in the neck. The RadDateInput control had a design flaw that used the MinDate as an empty value. Again this unintuitive behavior caused so many bugs and so much grief to new users, that it had to go. The RadDateInput control in RadInput 2.0 has proper support for empty values and its SelectedDate property is now of a nullable DateTime type. This had to be changed for RadDatePicker too: had we left it as is we would have done much to help customers as most of them used RadDateInput as a part of their datepickers.
Again, I apologize for the pain we have caused to both you and other existing customers. I hope it was all for the better. I would like to offer our help in your migration process: we can even post the lessons learned here so that they help other customers facing a similar problem.
the Telerik dev team