Regarding "Network Access·AuthenticationIdentityStore", that would be an additional optimisation for ISE, since this is an internal flag set by ISE to inform us how the Authentication was done. If during AuthZ you know whether Internal Users were used or External Lookups, you might be able to optimise your AuthZ conditions - e.g. if your AuthZ Rules are a mix and match of different things, where some apply to AD AuthN and some apply to Internal User AuthN, then you could make Network Access·AuthenticationIdentityStore part of the Condition. If you didn't do this, then ISE would have to brute force execute all the AuthZ Rules until it finds a match, checking things that make no logical sense, based on the AuthN that happened previously.
Honestly, I have never used this and perhaps I should, but I think it would be helpful in very busy ISE nodes, and one might also just think about re-factoring the Policy Sets to ensure they are organised to prevent this from happening in the first place. My top tip is to think of Policy Sets as a binary tree - try splitting the tree into logical branches as soon as possible, and avoid re-testing things you already tested before (e.g. only check the SSID once and then branch off, and use that as a context for further processing).
People who make one long Policy Set and then test for all possible conditions can learn a thing or two from computer scientists/programmers way of thinking.
