Just tried and it works for me. This tokenGroup thing is reported to perform much better than traditional nested groups which I used before. It was new to me, so good to have a look.
Did you apply the modified authentication source to the service? And did you do something with the attribute during role-mapping or enforcement? If you don't use/test an attribute, it will not be pulled as there is no change in the decision it's optimized out of your query.
What I did change in the Authentication source is that I selected the 'as attribute' to get it in the input tab of access tracker:
Then to trigger something I used a simple 'exists' check in the role mapping, but checking the S-number should work as well:
Then in an authentication, I see all the nested group ids:
I created a 3-level group hierarchy: Level 1 with member Level 2 with member Level 3 with my user. In the Nested Groups / tokenGroup, I see the SIDs for all three levels (and other groups the user is member of, like Domain Users):
S-1-5-21-1532318898-2625386876-3981842600-1114, S-1-5-21-1532318898-2625386876-3981842600-1115, S-1-5-21-1532318898-2625386876-3981842600-1116, S-1-5-21-1532318898-2625386876-3981842600-1609, S-1-5-21-1532318898-2625386876-3981842600-513, S-1-5-32-545
Ticking the 'as attribute' and testing the retrieved attribute are most likely the issue that you don't see them in Access Tracker.