So I now sort of understand why this was like that. Essentially: we just didn’t have consistent semantics for our unique constraints, since on Sybase, SQL Server, and DB2 the traditional semantics was that null=null for deciding uniqueness. And that wasn’t what we wanted for a @OneToOne with a FK.

Well, as of 2022, that’s been semi-fixed for a while in SQL Server and DB2. There is a way to create a unique index where null<>null on SQL server and on all flavors of DB2. For SQL server it is

create unique nonclustered index name on table (column) where column is not null

And on DB2 it is either:

create unique index name on table (column) exclude null keys

or, on i or Z series:

create unique where not null index name on table (column)

The only database where it’s still impossible is Sybase.

So my solution is, as kind of a second part of https://hibernate.atlassian.net/browse/HHH-15762, finally give our unique constraints on nullable columns a consistent semantic, and just refuse to create them on Sybase.