Is there a specific reason why we're not modelling LoadInstructions and have a getSourceAddressOperand predicate as a member of Indirection?

Yeah, there actually is. Since the Indirection class is defined by extending Type it means that every isAdditionalDereference that's implemented must ensure to also bind this to avoid duplicating the work across many Indirection classes. For example, let's suppose we implemented loading from a LoadInstruction by implementing the isAdditionalDereference class in PointerOrReferenceTypeIndirection like:

override predicate isAdditionalDereference(Instruction deref, Operand address) {
  deref.(LoadInstruction).getSourceAddressOperand() = address
}

this would definitely work, but since this doesn't bind this we'd have a cartesian product between all PointerOrReferenceTypes and the columns in this predicate.

I think we could fix this by implementing the predicate like this instead:

override predicate isAdditionalDereference(Instruction deref, Operand address) {
  address.getType() = this and // now we bind this so that every `Indirection` instance contributes a disjoint set of cases.
  deref.(LoadInstruction).getSourceAddressOperand() = address
}

but since we do actually want all LoadInstruction to be considered dereferences, I figured it was simplest to just implement this case outside the Indirection class.

A third option would be to avoid extending Type, and instead extend an IPA type. This IPA type would then have a branch for each Indirection we care about (the next PR will add an implementation of Indirection for iterators, for example), and we could implement PointerOrReferenceTypeIndirection by extending a unit branch of this IPA type to avoid the cartesian product between PointerOrReferenceType and the columns of isAdditionalDereference.

I see the problem now.

It seems that the IPA solution would require us to extend the IPA type every time we want to add a type of indirection, right? If so, that makes it more difficult for users to add additional indirection types (in the unlikely case they start digging this deeply), which is not ideal.

So lets leave this as it is.