Good point. Just mentioning the simplest things first, before potentially the most complex ones. Since he mentioned that he was already using iLogic tools to help solve this issue, but they were not working so far, I kind of wanted more details before suggesting more iLogic, but did not include the questions I had in mind, due to other distractions. It would have been nice if the existing example code(s) he was using were posted here, maybe as attached text files, that way we could review them, instead of shooting in the dark. Maybe the code he has is OK, but just not being ran often enough or when needed. Or maybe his codes are throwing errors or skipping past errors that need to be dealt with instead of ignored. Since there had not been any mention about them using 'design copy' or 'save & replace' strategies so far, so I did not want to assume anything quite yet, but just wanted more information to go on.
By the way, I think the block of code you posted could also potentially throw errors in certain situations. For example, if any of the components were suppressed, then the third line of code would throw an error, because it can not access the definition of a suppressed component. Also if any of the components represented ModelState members, it likely would not allow editing their document DisplayName property value...at least not until the factory document version was obtained/used, or similar counter measures for dealing with ModelStates.
Since the iLogic Event Triggers dialog only offers a limited set of events, and are not always the most efficient to use, a custom add-in may be the way to go here, as long as everyone on the team who has 'edit' rights had that add-in in place. We do not really know yet what is going on which is causing the components to not be named as their part numbers, so determining which events to monitor and react to is still needed.
Wesley Crihfield

(Not an Autodesk Employee)