The problem with changing only -one- instance is that there is no instance. An instance is a dynamically created in-memory parametric database that depends completely on the generic file. Many alterations to instances have the opportunity to change all the instances and changing an instance requires a change to the generic. The generic file is just a program that is used to generate other programs; as such any change to the generic should be seen as a change to all the instance programs that are created using it.
I think there is no benefit in thinking or treating instances as independent (even by name they are not independent.) Because of that I see that revising all the instances along with the generic is the only action that matches how instances function, just as changing the revision of all the sheets of a spreadsheet is the only action that matches how spreadsheets function.
Since this behavior is something your organization can't handle, then I recommend using Inheritance. It makes models that can be more difficult to maintain correctly than family tables, and it's very much more difficult to audit the models that come of using it, but at least the models will be independent so they can be revised independently, except for the main parent. If the main parent model is revised then all the parts that inherit from it should also be revised.
Back to the original question - is there error detection in Windchill for preventing failed family tables into Windchill and creating failed data structures based on them? It seems like all the data required to determine that the original version of the family table had certain members and that the new version is missing some of those members without an attendent inclusion of a same-named, replacement, non-tabled item.
Is it just a matter that there is no interest in the database integrity for family table items? This seems like a function that needs to be managed. As far as I can tell the only problem anyone has with family tables is due to integrity errors. Stopping integrity errors before they are committed in Windchill seems like a worthwhile effort. Whether they are independently revisable is a preference; the problem with handling that revision is an ERP problem, one which extends far beyond family tables.
Keep in mind there is a contingent out there that wants to be able to modify certain instances without touching the generic or other instances even though PTC's recommended practice is to treat the entire table as one when checking in. You would think it would be pretty easy for PTC to create a config option that hides the delete option in the menu of Creo parametric for family table rows. This is the source of the problem where the issue could be mitigated if removed. 
