Quote from Vladislav Vaintroub's comment to CONJ-117:

I think "Illegal mix of collations" is a problem.
I reproduce it from the command line client , and you should be able too.
create table h( c varchar(10) character set ascii);
select * from h2 where c='ä'; # any non-ascii character will work
gives
ERROR 1267 (HY000): Illegal mix of collations (ascii_general_ci,IMPLICIT) and (cp850_general_ci,COERCIBLE) for operation '='
The original problem was involved prepared statements (JDBC client-side), and UTF8 as the client side encoding, and latin1 column on the server side, but the essence of the problem is that if you have a character in the query outside of column encoding range, this ugly "Illegal mix" arises. Why would not the query just return an empty set.
There is another part of the bug, Marcel states he was able to insert non-latin1 into latin1 column, but I was not able to reproduce it .

Since we have a charset expert in the house, I'll leave it to Alexander Barkov to say whether it's really a bug.

Marcel was able to insert non-latin1into latin1 column, mostly likely due in non-strict sql mode, in which server replaces unknown byte sequences with question marks. So it is well possible to "insert" string into a column (at least there is no exception, so it kinda succeeds ), but impossble to query for it afterwards -there is an exception

> There is another part of the bug, Marcel states he was able to insert non-latin1 into latin1 column, but I was not able to reproduce it .
> Marcel was able to insert non-latin1into latin1 column, mostly likely due in non-strict sql mode, in which server replaces unknown byte sequences with question marks

Just to clarify this: I do not consider (the insert) this a bug: In fact I think this is expected behaviour. I've seen the same behaviour (replacing unknown chars to question marks) on oracle.