I see it has been some time since you posted your question with no response. Have you come up with an acceptable way to address the legal naming challenge you raised? If yes, might you share? If not, let me know and I will do some further digging to see if we can get an acceptable course of action for you.
We are still working towards and overall resolution on this issue. We have put in enhancement request with Ariba to allow for multiple legal entities much like it allows for multiple Affected Parties but they are not under consideration at this time.
Operationally we are using our AP enabled vendor as the legal entity and then using the affected party slot to attach any additional names or DBAs so that we can track what contract is with which organization.
We're still looking for additional best practices and hints and tips from other organizations that may face the same issue.
I wanted to add a comment or two:
If you have prevented additional or recurring problems, then that is good. Just remember it is very important to load the SupplierIDs.csv first. This links your ERP vendors with your upstream Common Supplier record through the ERPID and the BuyerSystemID. If this link takes place, you should for all practical purposes have stopped creating all of those duplicates.
When you say "the vendor cannot be changed if it has been published," do you mean that the supplier can't be changed because the contract has been published? If that's the case, have you tried changing it with a full Amendment or a Renewal? I don't know your configuration, so this might cause further complications, such as kicking off an unwanted approval task.
Also, in Upstream, in order to eliminate the duplicates, you can make the downstream supplier record a child of the upstream (presumably the correct) record and then inactivate the downstream record. When you do this, all of the projects (contracts, sourcing events, SPM projects) will now be associated with the new parent (This is the same functionality as is used in a true acquisition.) I'm not a downstream expert, but I think this activity will correct the downstream activities as well.
Note that these activities (establishing parents and deactivating) can be completed through data imports and exports rather one-by-one in the user interface.
Although making the correct supplier an affected party will help in searching, I'm not in favor of this, as a rule. First, it does nothing to correct the underlying problem; that is, the user can still pick the wrong supplier in the project - sourcing, contracts, SPM. More importantly, it confuses the real purpose of affected parties, i.e. parties that are actually a party to the contract. Also, this may help in contracts, buy there are no affected parties in SPM or sourcing, This leads to another objection and that is reporting. Affected Parties reports differently than supplier. For example, I might want to know all of the sourcing events and contracts for my supplier. We would not be able to use affected parties for that type of report.