That did occur to me and indeed it is in 9 previous versions of another assembly. Now given the "theory" of version history though....I can see how these references should never go away of course as a part insertion "in a past revision" needs to be kept track of in order to preserve the integrity of the history should that old version need to be promoted.
Now lots of users, including myself save judiciously after every few operations, as a matter of not losing work.....but in the current version schema, this creates lots and lots of versions; however, versions in this context is not the same as "milestones" you'd might want to save as a version in the context of a unique configuration.
For example, in SVN / Git version control systems...a SAVE is different from a PUSH or COMMIT. You can save your work many times, but then choose when to commit to a "controlled version" for later referencing. Perhaps the same concept implemented here would be nice. I would save 100 times in a day as I work, but only push the final version at the end of the day as a "configuration" I want to save and may promote int he future"....whereas adding a fillet and saving is not necessarily a feature I want to 'save as a version'. This puts the onus on the user to determine how much work to "save as a version" vs. how much they're willing to go back and redo should something bad happen (power outage) while they're working.
For today though, I see this as a "best practices" issue on my end. I'll just create a folder to hold "deleted versioned parts" and keep moving while you guys ponder "version theory" 🙂 Thanks again for your input!
TomK