[This feature was already released with 1.13.65, but with an invalid description.]
VB.NET has a very specific way of dealing with some operators, most notably string comparisons. The method call chain produced for an expression of
Therefore, the WhereClause produced by re-linq contains a Predicate with a MethodCallExpression invoking VisualBasic's CompareString method, whose result is then compared to 0.
A similar behavior occurs with many operators on other data types as well, such as Add or GreaterThan, but for thise, VB.NET does not produce MethodCallExpressions. Instead, annotated BinaryExpressions (with a MethodInfo indicating the operation) are created, so LINQ providers won't even notice the difference.
However, the VB operators do have very specific semantics; for example, VB compares Nothing and "" to equal (C# does not). Some LINQ providers might want to honor these semantics, others might not want to do so. LINQ-to-SQL does honor the semantics in part - if one side of a string comparison is a constant Nothing, it compares to string.Empty instead in the database.
To enable LINQ providers to deal with VB.NET specifics, this feature introduces a new VBStringComparisonExpression - deriving from ExtensionExpression - and an IVBSpecificExpressionVisitor interface. It uses the extension expression approach, which allows VB expressions to be visited by classes implementing IVBExpressionVisitor. The VB expressions are reduced to ordinary BinaryExpressions for = and <> and to MethodCallExpressions to String.CompareTo for <, <=, >, and >=. Most LINQ providers without VB support will never need to deal with those expressions (ExpressionTreeVisitor will automatically visit the child expression held by the VBStringComparisonExpression, ThrowingExpressionTreeVisitor will automatically reduce by default). LINQ providers with VB support can choose.
The VB transformation is always included, so LINQ providers already handling MethodCallExpressions to VB's CompareString should change their implementation and implement IVBSpecificExpressionVisitor instead.