My apologies if I misassigned the priority; I tagged it that high because a seemingly-mild refactor caused the SessionFactory to blow up with no clear resolution.

Thanks for addressing the issue, but I'm having difficulty understanding the background. What do you mean by a "reflexive" relationship--that it's directly between instances of two concrete classes? JPA 2.0 unfortunately states that "relationships are polymorphic" but offers no further detail on what it means by that. Also, I note your quotes on "foreign key", but I don't think I follow; the foreign key is Customer.id, and restricting the query to SpecialOrders is just an extra join (probably not even additional WHERE, since Hibernate doesn't use a discriminator column for type determination anyway).

I do understand that typing a relationship onto a subclass requires additional join information, but (a) it seems that at least a hand-written version of the join starting with the subclass and left-joining onto the superclass is straightforward to model, and (b) JPA already supports this type of "relationship" implicitly by using the TYPE operator, so all of of the information required to execute the join has to be present anyway.

On the other hand, moving the customer field onto the subclasses (which we immediately considered as a workaround) thoroughly breaks JPA field traversal, because we can no longer say

SELECT p FROM Payment p where p.forOrder.customer = :thisCustomer