(1) Please do not post images of code, post actual code text properly so we can scroll it and copy and paste it, edit it etc. (Please also use carriage returns so that we do not need to scroll horizontally.)
(2) When you have a test model that fails, please post the test model.
Really, because that 1 instance is within 1 definition (Shower Tray) that has 3 instances.
Which is correct.
I think you’ve had incorrect expectations.
In reality, there is only 1 instance of the drain. If you double-click into any of the 3 Shower Tray instances (you’ll then be in the definition’s entities context,) and you can examine the PID of the drain. Repeat for the other tray instances, comparing the PID, and you’ll realize that the drain is the same exact object in all 3.
What is being done here for count_used_instances is a hierarchy walking product that multiples the real uses with wrapper definition’s uses.
This kind of unreal expectation is why Thomas is questioning (in the GitHub issue tracker) whether this method should really return an array of InstancePath arrays, because if you expected an array of 3 drain objects, they’d all 3 be the same instance object. Which really will not help all that much.
Conclusion. The method I gave above is actually working correctly.
There is only one drain group instance, even though it is “used” 3 times by virtue of it’s parent definition having 3 instances.
Your mistake is assuming that the “used” array will have the same number of members as the “used” count. This is not true in all cases, but may be true in some.
However, Thomas’ example above has a error.
In his edition, the call to the model method needs to be: definition.model