John Ament I few points...

I disagree. This worked fine in earlier hibernate versions.

The fact that something used to (happen to) work in a previous version does not make something a regression (as in a bug). It has to be documented in some fashion to work that way. That's not my "rule"; that's just software development. This behavior you say "work fine in earlier hibernate versions" may have in fact worked for you in your specific case. However, as I mentioned in the referenced HHH-9714, support for that was (a) very inconsistent across databases and (b) not documented to work with schema tooling. In fact prior to 5.0 schema tooling was completely unsupported, provided as a "best effort" for use by the community. 5.0 changed that to make it supported, but part of that is refining behavior and expectations.

In addition, their documentation clearly mentions create database/create schema.

That is partially true. That linked documentation does in fact show that MySQL does support creating a database (catalog) via CREATE SCHEMA as a synonym for CREATE DATABASE (catalog). What it misses, however, is the querying of database metadata that is needed for schema validation/migration. Again, as mentioned in HHH-9714, if "MySQL supports database (catalog) and schema then why does querying database metadata based on schema not work? The issue here is reflexivity. They support SCHEMA in terms of creating a DATABASE (catalog), but not in terms of querying that metadata back.

When I initially developed this supported version of schema tooling, I had hoped to allow a level of application portability here in terms of porting the use of schema/catalog in mappings to the supported construct for the underlying database. But that ran into some problems. The idea was, in your case for example, that we'd see @Table(name = "types", schema = "config") and based on our knowledge that MySQL does not support schema, but instead supports catalog we'd simply interpret that as @Table(name = "types", catalog = "config") for you. This sort of implicit "intention interpretation" always has dangers though.

In principle I am not against adding such an interpretation feature here. IMO it ought to be an opt-in behavior. If that is something someone here is interested in starting development of such a feature, let's start a discussion about it on the hibernate-dev mailing list.