We issue families of similar tokens, for example one stablecoin per local currency for a partner: same admin, same rules, different instrument id and precision. Today every token is its own Daml package set, so each new token means a new package, vetting on every participant and integration work.
We plan to move such a family onto one package set: a Holding where the instrument is data (admin plus instrument id), one factory per admin, and one configuration contract per instrument (issuer, precision, pause, freeze) passed through the choice context. A new token is then a configuration contract plus a registry entry, no new package. Built on the Token Standard V2 interfaces; your Utility registry (InstrumentConfiguration plus a shared Holding) is the precedent.
Is this the layout you would recommend, and which pitfalls have you seen: upgrade blast radius of one package per family, cross-instrument input mixing, binding the configuration to the right instrument, rotating it while transfers are in flight, or wallets and scanners assuming one package per instrument?