I think we need to define a short-term and a long-term fix for this. The reason is basically that annotation processing has not yet gotten the full TLC from metamodel branch. So for sure there will be changes here again later. Not as disruptive as this time around, but changes none-the-less. We can get into the whys and hows offline if you want.

So basically this issue requires a (more or less) mutable view of the MetadataBuildingOptions. The first question is how mutable do we want to make this? I am kind of loathe to make everything mutable. The only use case we have internally in ORM is this "JPA orm.xml-defined persistence unit defaults". So for my use cases, I only ever care about this one method #apply(JpaOrmXmlPersistenceUnitDefaults).

In the metamodel branch approach, this would get handled by contextual, delegating MetadataBuildingOptions impls. But again annotation binding in master/5.0 is not set up for that. So in the short term, I'd suggest a separate (optional?) contract here... a "JPA orm.xml-defined persistence-unit-default aware MetadataBuildingOptions". I know how much y'all love my descriptive contract names so I'll ask you what we should name this. For now:

/**
 * Contract for things that need to be aware of JPA {@code orm.xml}-defined persistence-unit-defaults.  Only
 * MetadataBuildingOptions are supported to implement this contract.
*/
public interface JpaOrmXmlPersistenceUnitDefaultAware {
    public static interface JpaOrmXmlPersistenceUnitDefaults {
        public String getDefaultSchemaName();
        public String getDefaultCatalogName();
        public boolean shouldImplicitlyQuoteIdentifiers();
    }

    public void apply(JpaOrmXmlPersistenceUnitDefaults jpaOrmXmlPersistenceUnitDefaults);
}