This is particularly difficult to replicate, but I will try to post something shortly.
This was exposed when a SolutionSet? containing some MemTypedLiterals was joined with RdbNodes of various types. The results of the join were clearly wrong and eventually it became clear it was only if typed literals were in the mem solution set that the issue occurred.
The culprit's are compareTo methods in the RdbLiteral and RdbURI node classes that compare by ID against each other rather than by lexical value. In isolation, these node classes seem to establish some kind of consistent order and can be joined against each other quite well, and very fast.
Unfortunately, this internal ordering doesn't seem to extend fully to mem nodes, particularly literal datatypes (blank nodes seems to have issues as well).
To verify theory, I have commented out (but not checked in) the 'by ID' portions of the compareTo methods in the RDB node classes. This forces the implementations to fall back to performing all these operations on the lexical values of the nodes. This does in fact result in correct join behavior. However, since there is a huge performance benefit to using the IDs for comparisons, I think it's clear that this issue is best resolved by fixing the ID scheme to handle literal datatype (and presumably lang) tags as well as verifying blank node labels are working okay. (I do not know how the IDs are selected or if this is possible, yet, but it does _seem_ to _almost_ work).
This is not an entirely unknown issue, from RdbLiteral.equals:
via the definition in:
// http://www.w3.org/TR/rdf-concepts/#section-Literal-Equality
// we need only compare the lexicalizations of the two literals
// since the lexicalizations include the language tag and datatype
// parts
Note that this is a major issue since SPARQL queries behave erratically whenever not all the RDF is backed by RDB nodes.
