Another approach is to have "blocked variants" instead of "reserved
variants". A "reserved" variant belongs to exactly one package, so
you can activate it without checking for conflicts. But a "blocked"
variant would not be reserved for just one package, it could be a
blocked variant of multiple packages. Therefore, before you can
activate a blocked variant of a package, you need to check whether it
is also a blocked variant of any other packages (and check for any
other restrictions on its activation). When packages are presented
to registrants, the blocked variants would not be shown, because they
don't belong to the registrant. The registrant will not know whether a
variant can be activated until they try (because inactive variants are
not reserved for just one package).

Sound like a possible solution altho I dont like the last part regarding
"guessing". But it might work.

I just thought of a related problem. Suppose W and X are variants, and
X and Y are variants, and Y and Z are variants, but no other pairs are
variants. Suppose someone registers W, which reserves X, and someone
else registers Z, which reserves Y. The two registrants can then
activate their reserved labels, and now X and Y (which are variants) are
registered to different people.

Yes. But X & Y are variants in some context (language) which is
different from what makes W & X variant and Y & Z variant.

Hence, in this case, what we ends up with is a package1 of W & X and
another package2 of Y & Z and no one can own a package of X & Y. Neither
package1 nor package2 registrant would "complain" because they already
got what they want as far as their concern.

The person who wants the package for X & Y couldnt get it because of
FCFS. No diff from existing FCFS.