Summary: 

[Brian Skinner] I think we should design this all so that XML datastores and JSON datastores are interchangeable. The UI code, and the table binding, should be insulated from needing to know what sort of datastore they're connecting to. Which I think means we should avoid using XPath here.

[CCM] I agree, and that was the intention of the original api, but in practice, implementing general XMLStore in a path neutral-way and trying to use them behind current api has exposed that the current api needs to be more clearly specified.  In removing xpath for general XML case we delegate the mapping knowledge attribute vs. text() content to the datastore implementation.  This requires XMLStore implementations to have some knowledge of schema in order to get/set values.  For example, OPMLStore can do a straightforward mapping becuase it has implicit knowledge of it's particular schema (OPML schema) mapping for attributes--however, this is not possible in the general case XML unless schema hints are available for the XML document being accessed.  This schema info could be just an option to always map to attributes or always map to childElements in the simplest case, or could actually be implemented to use XSD/DTD info if available.
The "don't use native access path" in prop names rule needs to be documented in the api--it's currently unclear that it was designed to be path-neutral.  At the same time, it's also possible that the api could be loosened to allow use of native path to the ds if you know you're always going to work with a particular kind of data.  For example, using escape string at beginning of path, "xpath:foo.text()", or just ":foo.text()".  This supports the case where you dont care about interop, but want to make use of the power of the native datastore's path language.
Also, in terms of the P01-P03 below, I believe all three cases are valid and necessary, in the following order of importance (simple->advanced), P02, P03, P01.
ISSUE: P01 needs to be further refactored, to assume that datastore is same for all values displayed in the grid.
ISSUE: How to support different labels of columns vs. property names in P02 & P03.

Scenario:

Programmatic:

Assumptions:
1) Allow data property names to be different from column column names
2) Arbitrary event on a widget can be used to triggers the bind

TABLE_P02: Grid widget with custom column binding -- an alternate appraoch.

// This example (P02) tries to accomplish the same task as the example from TABLE_P01 above, 
// but using a (hopefully) simpler approach. 
// This example also tries to avoid any XPath or XML-specific notation.
// And we also use a hypothetical new Grid widget instead of the old FilteringTable, so as to
// avoid having to use legacy API.

var store = new dojo.data.CsvStore({url:"books.csv"});
var grid = new dijit.Grid({datastore:store});

Assumptions:
1) A 1-1 mapping of data property names to column names, and the set of all data property names equals the set of column names (eg. the grid's columns cannot be a subset of the data...they are a direct view of the data)
2) Standard event is available on all widgets that is used to triggers the bind
3) All data values displayed in the grid originate from same datastore

TABLE_P03: Another alternative -- this time with explicit column mappings:

var store = new dojo.data.CsvStore({url:"books.csv"});
var grid = new dijit.Grid();
dojo.data.bind({
	widget: grid,
	datastore: store,
	mapping: {columns: ["isbn", "title", "author"]}
});

Assumptions:
1) A 1-1 mapping of data property names to column names
2) Standard event is available on all widgets that is used to triggers the bind
3) All data values displayed in the grid originate from same datastore

Declarative:

<table dojoType="TableGrid" id="widget_A1" dataSrc="#dataIsland_A"></table>
<table dojoType="TableGrid" id="widget_A2" dataSrc="#dataIsland_B"></table>
<table dojoType="TableGrid" id="widget_A3" dataSrc="#dataIsland_C"></table>
<table dojoType="TableGrid" id="widget_A4" dataSrc="#dataIsland_D"></table>
<table dojoType="TableGrid" id="widget_A5" dataSrc="#dataIsland_E"></table>
<table dojoType="TableGrid" id="widget_A6" dataSrc="#dataIsland_F"></table>
<table dojoType="TableGrid" id="widget_A7" dataSrc="#dataIsland_G"></table>
<table dojoType="TableGrid" id="widget_A8" dataSrc="#dataIsland_H"></table>

TABLE_D02: TableGrid? with simple bindings to data stores. No need specify columns, since we can get that info from the data store.

<table dojoType="TableGrid" id="widget_C1" dataStore="#dataStore_A"></table>

TABLE_D03: TableGrid? with simple bindings to data files. No need specify columns, since we can get that info from the data file.

<table dojoType="TableGrid" id="widget_D1" dataSrc="url:datafiles/booklist.csv"></table>
<table dojoType="TableGrid" id="widget_D2" dataSrc="url:datafiles/booklist.xml"></table>

TABLE_D04: TableGrid? with specific bindings that give column order, sort order, data formatting, etc.

<table dojoType="TableGrid" id="widget_E" dataSrc="#dataIsland_F">
	<thead><tr>
		<!-- No need to give column names, since the data store will provide them -->
		<th attribute="#author" editable="true"></th>
		<th attribute="#title" alignment="center"></th>
		<th attribute="#pub_date" sort="asc" format="%b %d, %Y"></th>
		<th attribute="#pages">NUMBER OF PAGES</th> <!-- Can explicitly give a column name -->
	</tr></thead>
</table>

See also TABLE_P01

TestCases:

Programmatic:

Declarative:

Discussion: