Hi @nathan_m_gardner. This has been a pretty popular topic in this forum for many years, with many discussions about it, and many 'solutions' posted for it. As you have found out, it is not a very simple task, and there can be a lot involved. One of the most helpful tools, or most troublesome stumbling blocks (depending on which side you are on), is the DVRs (DesignViewRepresentations). These are present in both parts, and assemblies.
When you are in a part, there will be a 'node' near the top of the model browser tree with a name starting with "View:", and ending with the name of the 'currently active' view, which can be expanded to see the individual view representations within it.
When you are in an assembly, there will be a node near the same location named "Representations", which can be expanded to show sub categories for view representations, and positional representations, and so on.
By default, there is only one view representation named either "Master" (in older versions) or "[Primary]" (in newer versions), and it will be 'Locked' by default, meaning it will not record/save visibility related changes to the file, and it can not be unlocked. So, it is up to us to create a new/custom view representation that is unlocked, and activate it, if we want it to 'record' visibility changes, and 'reliably' see the model a specific way (such as all that stuff visibly turned off or hidden). The view representations are what record things like colors, appearances, object visibility, and such (not object suppression).
If the only view representation you have in the model is a 'locked' one (like the original one is), then any of those types of changes that you make while that 'locked' view representation is active, will not be recorded by that DVR. I have made it a point to include at least one 'custom' view representation (unlocked by default) in every new part or assembly that I create, by including it in all the templates that I start from, and making sure that 'custom' one is the active one.
Now, when we place a component into an assembly, we can set that one, individual component to specific 'representations' that are available within the 'source model file' that the component references. That includes ModelStates, DVRs, and positional representations. So, I always set my components to the 'custom' DVR, and set it to 'associative'. That way, if that view representation of that part changes in the source model file, those changes will immediately be reflected in the assembly component. On the other hand, if your source model file did not have any representations, and you place a component of it into an assembly, you do not have any options for setting it to a specific representation, so whatever the source model contains will be visible in the assembly component, and the only option you have is to edit the source model to turn the visibility of those things off. So yes, the best way to do this is to edit the original model files, create a custom DVR in them, then activate it, and while it is active, make all visibility, color, and appearance changes needed, then save the model file. But were not done yet, because now we need to go back to the component occurrence in the assembly, and set that occurrence to the view representation that we created within the source model file. Now, we may still not be done yet, because we have to keep the assembly's own DVR's in mind. For example, which DVR in the assembly is currently active? If it is a 'locked' one (like the original one), then those settings for the individual occurrences will not be saved properly. So, make sure the main assembly has a custom DVR, and that it is active, before setting all those individual component occurrences representations the way you want them. Without any representations being involved, it can be chaos. But all that is not nearly as much work when it was all being done as each model file was being created, which is how our shop does things. If none of that was done in preparation, then large, complex, recursive automation codes start needing to get involved to drill back down through all of that and do all of that work later.
Wesley Crihfield

(Not an Autodesk Employee)