Indirection is one of the technical details it's useful to understand about FileMaker and how BaseElements generates "references" and therefore also generates its list of "unreferenced" items. Hopefully this explains indirection a bit better for those who don't understand the concepts.
First of all, lets consider calculations that use a field. If we have a very simple calculation like :
List ( relatedTable::textField )
Then BaseElements will "see" that reference, and will count it once towards the reference count when we look at textField in the Field list. However we can also do things like :
GetField ( "relatedTable::textField" ) Evaluate ( "relatedTable::textField" )
In this case, the DDR treats the text as a string much like it would "someText Here!!", and the DDR doesn't include any references for content inside strings. So BE doesn't interpret the content of text so there's no references generated from the above - even though you would "know" by looking at it, that it contains a field.
So there will be no count for this calculation, and if this was the only place this field was used, then this field may not be included in the reference count.
The question that gets asked a lot is why not? It seems obvious that this is referring to a field. The answer, is yes, but ... :) So to complicate things, lets look at some other examples :
GetField ( "relatedTable::" & $userData ) Evaluate ( "relatedTable::textField" & $variable & " & CustomFunction ( relatedTable::OtherField )" )
Both of those calculations are valid, and you soon realise that if you're going to understand the first ( simple-ish ) example, then you should also try to pick up the two complex ones, and next thing you know, you're writing a FileMaker calculation parser. Which is an exercise best left to either someone at FileMaker or someone who is crazy enough to attempt it ! Writing a calculation parser would be a massive undertaking and I've not seen an from Claris to suggest that they've written documentation for their own parser, so you'd be assuming that you've got everything correct.
In other words, even if we wrote a calculation parser to sit inside BaseElements, it would catch everything, and there's no guarantee it would be complete.
About catching everything the calculation GetField ( "relatedTable::" & $userData ) could referent to relatedTable::Field or relatedTable::otherField or relatedTable::whoKnows. So which does it reference? It depends on the content of $userData at runtime. Which BE doesn't have access to. Perhaps the script limits the result to either Field or otherField but you wouldn't know for sure. And you're not even sure that relatedTable:: is a table reference, maybe it's not, it could be just part of a dialog that comes up.
Then if you only limit the text parser to working out which ones are specific field references, then your assuming that your parser works 100% of the time. Without specifications from Claris, this is still a big unknown.
So at this point, I've made the assumption that it's not worth trying to build a parser that a) won't solve all the problems and b) may not be complete anyway.
I think the better solution is to track what aspects of your solution use indirection, so you can know about them. Then you can make decisions about whether to use Indirection or not, AND you can use other methods to reduce the effects of it.
What can I do?
Firstly, you can get field names via calculation, so when you you need to reference a field name inside a text string, use something like GetFieldName ( myTable::myField ) to get that detail as text. As you can see, the field name isn't quoted, so this counts as a reference.
Second, just because a field is inside text doesn't mean you can't find it with BaseElements. You have full Find functionality so you can search across every single calculation in the solution, and there's also the QuickFind option which finds within any bit of text anywhere, including layouts and comments.
We'll also write up a comprehensive document about all the places that you can find where Indirection is used in BE, so keep an eye out for that.