I understand there goal,
make the central library match the pads flow,
but lets face it , the PADS layout needs only DXdesigner attributes translated to PADS layout attributes. and dx designer needs nothing all all from PADS layout.
Forcing Pads schematic nomenclature and rules onto dxdesigner simply makes a ton of legacy Dxdesigner stuff that worked fine now completely unusable.
If the packager ignored schematic related stuff like the netlist flow currently does , I would have no problem.
My Large scale problem is , I have a dxdatabook with 1200+ parts , schematic symbols with 2500+ parts, and a PCB decal library with 2000 + parts. I admit not all of this is correct and properly linked , BUT in a netlist flow, it all works on pretty complex designs, and is easily corrected when a problem is identified , AND none of it contains any Pads schematic related things.
We never used Pads schematic entry and as a NOTE: in the latest VX , they do not even include it in the install. so why force me to reference an incompatible AND ALSO NOW obsolete format for migrating data to a central library. remember , the central library data still has the same symbol data base and Pads pcb data it had before. my issue is forcing the use of the packager which is obviously from Pads Schematic to Pads PCB and not making it work with the dxdesigner architecture, which is going to be the new long term entry standard anyway.
They also tossed in another wildcard as well , they are integrating Expedition into this mix. It appears to me that expedition is the final goal in the long run. so now 3 things to mix up and muddle the process.