Based on the number of questions in this thread you should contact your customer support organisation to try and get resolution. We've not had any other reports of such issues and checking this morning we cannot reproduce similar issues. What does the .asc file list for the parts? Can you create a small block in a new project, add a few components, create another instance and package this design, going from DxDesigner to PADS but checking instance level REFDES before opening in PADS. It all seems to be working as expected in a simple test case, no interconnected nets between blocks even for nets with the same name that shouldn't be connected.
Are you using the correct hierarchical port connectors inside the block to map between the block and the underlying schematic. Are the nets at the top of the design unique per block etc.
The RefDes Suffix property is not intended for the PADS flow as far as I am aware, it isn used in the Expedition flow. Somebody with greater knowledge of PADS may correct me on this point if this is not the case.
Thanks for the reply. As it turns out, the the pads95.cfg file was modified - possibly a previous user? Anyhow, a quick diff in a text editor showed a few issues, the key being that the "pkg device" property wasn't listed under specific attributes to pass, but under general. Fixing that got the refdes and backannotation working just fine.
As for the hetero devices, I misspoke - it was a type 2, NOT a type 4. From what I understand, a type 2 can't be used in this type of design - when the external nets are resolved into the block instance, they end up conflicting with the net names on the signal properties assigned to the type 2 hetero devices. A net alias might work or if the power nets weren't connected to IO pins. My solution was to change them into type 3 devices.
As for uniquely identifiable information on eash block instance, I added a refdes to the block.