I understand how a DynamicQuery-like syntax for collection.Filter would be very useful. The more hard-coded strings you can eliminate, and the more errors that are caught at compile-time rather than run-time, the better. The enhancement request is in our tracking system, but the implementation is not a simple one, as Mike pointed out in the linked post.
However, I think you are confusing database-specific SQL syntax with the .NET DataColumn.Expression syntax. Whether you wrap SQL Server date literals in single quotes, or MS Access date literals in pound signs, is un-related to Filter expressions. Expression literals are dependent on the column's .NET datatype. For DateTime columns, literals are always wrapped in pound signs, i.e., #date#. String columns are wrapped in single quotes, i.e., 'string'.
If, in a particular filtering instance, you need to do this - 'date', it is because the column that contains the date representation is defined as a string column, not because it originated from SQL Server. EntitySpaces collections contain DataTables of Columns with .NET System.DataTypes that have been converted from db-specific types by the EntitySpaces providers. Any Filter expressions applied to them are already provider independent.
David Neal Parsons
www.entityspaces.net