<two-cents>
I see why this is happening with 5.0.3 but I think that fields with custom AttributeConverters should allow use of the Converter's DB type in the @Query string without causing an Exception.

The recommended method of handling Enums with custom AttributeConverters all over the internet is to put a String literal in your @Query string for the DB value you want to match. I understand that this worked because of a bug, but I don't think it makes sense to complain about the type mismatch when your AttributeConverter converts to/from String. Especially since using @Enumerated(EnumType.STRING) on the property works properly with the String literal in the @Query string.

There's a couple layers of inconsistency there to my mind and coupled with the mass of stackexchange posts telling people to do it the old way I think there's a strong case to be made for reverting this to the 5.0.2 behavior when using AttributeConverters.

Failing that, fixing to work with Outer.Inner.TYPE1 would be my preference as this is less wordy than the current com.company.project.model.Outer$Inner.TYPE1 and it doesn't use the unexpected $ separator.

It took me quite a while to find the current solution and I think this report may be the only place on the internet it is documented. Even the note at https://github.com/hibernate/hibernate-orm/blob/5.0/migration-guide.adoc#migration-from-502final-to-503final provides the wrong information. It doesn't mention the FQN or the use of '$' separator.
</two-cents>