I'm not sure who this should go to - adding a few folks as FYI.

Currently, we support tracking dependencies on custom queries (eg. I create a custom query called MyQuery, I then create another custom query, OurQuery, using values from MyQuery. MyQuery and OurQuery will both accurately reflect that there are dependents). https://www.labkey.org/Documentation/wiki-page.view?name=queryDepend

It came up in a meeting today that the client would like to extend this behavior to also show any dependencies that happen via lookups. For example, if I create a list, ListofColors, and another list, ListofAnimals, that looks up to ListofColors, it would be great to see that ListofAnimals is dependent on ListofColors (and ListofColors has dependents). 

Seems useful in the case of wanting to know truly what might depend on your lists and other tables.

I think the hard part of this would be not drowning the user in uninteresting system lookups. Lookups get created in so many ways, with so many classes. We don't know after tables are constructed how FK's got defined.

a) most user defined lookups are probably implemented using PdLookupForeignKey or QueryForiegnKey. But a most QFK are not user defined and many PLFK are not user defined.
b) we would probably consider lookups defined in XML loaded from the database as user-defined, but those defined in module files as not user-defined?

This would probably require adding a FK property "isUserDefined()" and modifying the code that loads domains, and xml overrides to tag them appropriately.

I suppose another way to think of this is filtering to only show lookups _to_ user defined tables, as most lookups to user-defined tables will be user-defined. There are exceptions, but those could probably be handled case-by-case. There is not user-defined table bit, that would probably be easier to sort out.

Thanks for thinking about this.
If I'm understanding your last comment, Matt -- would that mean that from ListOfColors we'd be able to say that ListOfAnimals is dependent on it? If so, I think that's definitely the most useful scenario to support (ie. don't delete this list because there are things that care about it!)