The plain constants are a bit greedy with the constant pool. The amount of slots will amortize towards one slot per entry if enough are used, but for smaller collections it could be 2-3 slots per entry. Nevertheless these could be quite handy in certain circumstances where you have a small fixed set of, say, classes that you only use in one or two places and you don't want to go through the ceremony of setting up a field for it.

The resource-backed collections are unbounded in maximum size, however they will take up several constant pool slots (amortizing to 1 or 2 per collection if enough are used in one file).

In other words, this means there's constant pool overhead in each class that uses this mechanism, due to condy, but it's fixed regardless of how many collections/elements are used. Right?

Looks reasonable on the first sight.

The plain constants are a bit greedy with the constant pool. The amount of slots will amortize towards one slot per entry if enough are used, but for smaller collections it could be 2-3 slots per entry. Nevertheless these could be quite handy in certain circumstances where you have a small fixed set of, say, classes that you only use in one or two places and you don't want to go through the ceremony of setting up a field for it.
The resource-backed collections are unbounded in maximum size, however they will take up several constant pool slots (amortizing to 1 or 2 per collection if enough are used in one file).

In other words, this means there's constant pool overhead in each class that uses this mechanism, due to condy, but it's fixed regardless of how many collections/elements are used. Right?

More or less. Each collection needs one constant pool entry for the collection itself (as of my most recent code). A certain amount of constant pool entries are used by the bootstrap method(s), but those only need to be generated once (per collection type) even if many collections are used in the same class. That's basically it.