The "explanation" about splitting types is really just a future statement. This has been the path I started down back when I first added AttributeConverter support into Hibernate. What I mentioned above simply being the logical end-game of that design. I just mentioned it in terms of how I see this playing out long term.

As for what you label "unsupported use cases", I think the point you miss is that you have very explicitly told Hibernate how to map these values. In HBM mappings, when you specify type="something", something is the thing that is used - period. That is by design and it is for a reason. In your example, telling us that type="binary}" very explicitly tells us to use {{org.hibernate.type.BinaryType:

/**
 * A type that maps between a {@link java.sql.Types#VARBINARY VARBINARY} and {@code byte[]}
 *
 * @author Gavin King
 * @author Steve Ebersole
 */
public class BinaryType ...

Notice especially the Javadoc comment : maps between a {@link java.sql.Types#VARBINARY VARBINARY} and {@code byte[]}. That is important. These types, as defined today in Hibernate, statically bind together a Java type and a JDBC type. And you told us to use the one that uses VARBINARY for the JDBC type. I don't ever expect that to change; if a users explicitly tells us the org.hibernate.type.Type to use, we will use that Type. Makes sense right?

What I suggested in terms of (a) a custom Dialect or (b) altering the BasicTypeRegistry is to account for a slightly different use case. Namely, the case where you had left off the type="binary" in the HBM. That is now an implicit type resolution.

There is one other option you could try. I was leery to suggest it, and I will explain why in a bit. But the idea is to leverage another capability built into Dialect to be able to "remap" a SQL/JDBC type (as in the SqlTypeDescriptor I mentioned before). The idea here is that you want to remap the SqlTypeDescriptor for VARBINARY/LONGVARBINARY to the SqlTypeDescriptor for BLOB. See org.hibernate.dialect.Dialect#remapSqlTypeDescriptor and org.hibernate.dialect.Dialect#getSqlTypeDescriptorOverride. Now the reason I was leery to mention this was because size information is not available in these methods, so it is not as useful as it would be earlier when we "resolve" the types, which get more into my future statement. So you can play with that method. That would work even in cases where you have explicitly specified the Type.