In the pipeline, [System.Data.DataTable] is still treated as a collection that implicitly enumerates its .Rows collection - through a mechanism that is unclear to me, given that it in other contexts this is currently, though possibly only temporarily, disabled (see #6453).

Given that [System.Data.DataTable]:

• itself has no .Count property
• is not itself indexable

the behavior with member-access enumeration - use of .Count and indexing - is not as expected:

Steps to reproduce

# Create a sample data table with 2 rows.
1..2 | % { $dt = [Data.DataTable]::new("test") } { $dt.Rows.Add($dt.NewRow()) }

# If we assume that [DataTable] is a collection, this should be equal to $dt.Rows.Count, i.e., 2
$dt.Count

# If we assume that [DataTable] is an indexable collection, this should return the
# type name of the 2nd row, $dt.Rows[1], i.e., 'DataRow'
$dt[1].GetType().Name

Expected behavior

2
DataRow

Note: If [DataTable] itself is NOT conceived of as a collection, the expected behavior would be:

1  # a single [DataTable] instance
You cannot call a method on a null-valued expression.  # Error, because index 1 doesn't exist.
...

Actual behavior

1  # post-#5756 only: member enumeration was applied to the items of .Row
1  # ditto
You cannot call a method on a null-valued expression.  # Error, index 1 was applied to $dt itself, not the .Rows collection
...

Note: $dt.Count returning 1, 1 is only seen with @iSazonov's #5756 PR in effect, which has not been released yet as of PowerShell Core v6.0.2; without it, $null is output, because the row objects lack the implicit .Count property.

Environment data

PowerShell Core v6.0.2 on macOS 10.13.3
PowerShell Core v6.0.2 on Ubuntu 16.04.3 LTS
PowerShell Core v6.0.2 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
Windows PowerShell v5.1.15063.674 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)