I guess what I really meant by that title is that I don't want to be told by NNA that Workgroup Referencing is their answer to TeamWork.
Catchy phraseology for something that allows Groups to Work on Multiple files Referenced one into another. It at the moment is just a very dumb computer Referencing as you point out.
For instance if you add classes in File A that is referenced into File B, File C and File D via Design Layer Viewports those classes will not Automatically be turned on in these other files until the other user activates them, that is if they are even aware the classes were added.
If in the same example above you rename all the Layers in File A then all the Design Layer Viewports are nothing but loci in File B, File C and File D making it virtually impossible for an average user to locate them for selection. One has to use either the Navigation Palette or the Organization Palette to turn on what in essence are the same Layers just with new names via an edit of the Viewports in the List. And this only works if you have named the Viewports to their purpose.
All human involvement and time for something that would seem that the computer should handle.
Maybe the one file system at present is the only way to handle this issue, but as in Multi File Databases, similar to FileMaker, one can segregate Data Sets into different files while each is connected actively updating as changes are made in each.