Rather large issue with cache retrieval

We've just been chasing the worlds simplest query against a table of users with four fields; userid, firstname, lastname, mobile. The view is marked as having it's key on userid (which is unique).
We have a query that selects all the users where firstname = 'David'.
There are two records in the database meeting this criteria, yet DF only returns one, no matter whether there is an order or not (so it's not just the first record, it's the only record), yet both records are indeed in the context's cache.
In addition, the query seems to be case sensitive, so 'david' fails but 'David' succeeds.
Tracing the server shows that the two records are returned, and specifying no filter returns all 27 users.
However, setting the context's default to QueryStrategyDatasourceOnly resolves all the problems and the system behaves as expected, two records returned, no case sensitivity.
This is running in an MVC2 app, not Silverlight.

A last second check of our database (just before posting this) showed:
[David ]
[David]

So it appears we have a spare space, but the crucial thing is that SQL allows for this in a WHERE, but the cache doesn't.
For now we've disabled the cache, but having the cache give back different data to the database is a significant issue. Any ideas? Is there an option to make the cache string comparisons SQL compatible?

Unless I'm missing the point here, this seems to be a quite serious bug/error/feature, certainly with regard to SQL queries.
The idea that turning on caching would return inconsistent results is a worry, primarily because every developer expects a cache to be transparent. In this situation there is no way to test for this issue in advance unless your testers know they have to include trailing spaces, experiment with case, and presumably experiment with extended characters?
Switching between online and offline modes also becomes extremely risky, and I know that we will have to turn off all the client-side caching until we can find a workaround; and insisting that every call to the database is wrapped in trim and touppercase certainly doesn't sound an acceptable option, particularly given that presumably these will pass through to SQL on the first call as UPPER(TRIM(fieldname)), probably removing index functionality.

Re property interceptors, what if (as in our case and probably many others) the entity is not written to the database by our application?

I would argue that a cache should be 100% transparent to the underlying dataset, and that this is a critical issue to be addressed.

One thing I do wonder (but have not tested) is what happens with other datasources in EF? Is the case-sensitivity and whitespace ignoring common to all EF datasources, SQL only, or MS-SQL only? If so, can you ask EF whether a datasource is ignoring case/trailing whitespace?