There are several undocumented methods on the data source which provide some really nice functionality. The DataSource is able to store multiple 'pages' of data in an internal collections of ranges that can be accessed and populated by the range() and prefetch() methods. It looks like this is used mostly to support virtual grid scrolling, but I have found it very useful for other applications where a data source uses server operations. This is a really great feature and I'd like to see it officially supported in the future!

Would be good to have ability to to something like this on an observable object:
o.set({ a: 1 })
I.e. pass an object to the set function to update/add properties in o from that object.

The HiearchicalDataSource should support XML data binding. If not, then the examples and documentation should be updated until that support is present.

At the moment, the DataSource only uses one field for its ID property (if you enter several, then only one is used, apparently).  This doesn't reflect reality, in that in many cases (where one record is a child of another), the key field for a database table is a composite (from 2 or more fields).  
The existing situation causes problems in inline editing of the KendoUI grid, because default values need to be set for foreign key fields, but if these are set to a valid value, then spurious calls to the Inline_Create method occur because the DataSource treats the record as a new record when it is not.
In any case, allowing multiple fields would simply reflect reality.

Currently, when binding an observable viewModel to a date/time picker control, only date formats built in to the widgets ( a minimal set) and formats specified implicitly by the ParseFormats option. 

I understand the reason for this being to prevent users from being able to type a date or time into the widgets in a format other that what is deemed appropriate for the widget, but it should behave differently when being bound from a view model.

Different platforms and web APIs serialize dates in different ways and developers should not have to always write a custom parser into the kendo datasource schema  for each datetime property of an object or have to specify the ParseFormat on the widget just so it can be bound properly to a date/time picker widget.

In the latest release (as of this posting) the parsing of Microsoft's JavaScriptSerializer date format has been added, ignoring the ParseFormats of the widgets. This is a great step in the right direction, however the W3C standard ISO 8601 date format is not being parsed while bypassing the ParseFormats of the widgets.

Also, currently, the date parser will not allow parsing of ISO 8601 date strings with more than 3 decimal places for fractions of a second. Both Microsofts DateTime.ToString("O") and Newtonsoft's Json.Net's ISO serialization of dates output 7 decimal places for fractions of a second. (I have been in contact with the kendo team about this specifically and they are going to add support, however they are not currently planning to make it bypass the parseformats unless the community votes for it here on UserVoice).

Since Kendo has specific functions used for binding widgets and elements, they should be able to easily make it so all parseformats (built-in and implicitly specified) are used when parsing dates that are set using binding to widgets expecting an actual date object and not a string (the date/time pickers).

See this forum post for details: http://www.kendoui.com/forums/framework/mvvm/getting-access-to-array-index-while-binding-an-array-source.aspx

In the context of MVVM bindings, it would be great to have a way to evaluate certain conditions/expressions, especially within template bindings, by "navigating" to other properties of the ViewModel, or to other properties of the currently iterated object.

For example:

<ul data-role="listview" data-bind="source: anObservableObject" data-template="some-template"></ul>
<script id="some-template" type="text/x-kendo-template">
    <li data-bind="text: whatever, visible: $source.someProperty == $data.otherProperty"></li>
</script>

In this example, $data refers to the current iteration data, and $source refers to the source. So the visible binding would be true/false according to the expression which would evaluate an arbitrary property on the source and an arbitrary property on the iterated object.

This is similar to Knockout's mechanism and it allows for greater flexibility within templates.