Priority ID Scan is confusing and it doesn't behave like you think it should when you are used to conventional frequency priority scanning. The current "way" of how priority scanning is done hasn't changed for several scanner generations (as in it has been at least this way since the BC396T came out 14 years ago).
On the trunked side, at least for the majority of system types (which does include P25), there is no pre-emption of non-priority transmissions to see if there is activity on a priority talkgroup. Only when the control channel is being monitored for channel grants will it "yield" to a higher priority talkgroup.
An example: Let's say you have Talkgroup A set as a Priority Talkgroup and all the correct settings are made for Priority ID Scanning. You are holding (Channel Hold) on Talkgroup Z and there are no transmissions going on "Z", and haven't for a few minutes. If Talkgroup A (your priority talkgroup) becomes active, the scanner will "jump" from Z to A and you hear the conversation.
Also, there is some "one way" priority stuff going on. Same scenario, holding on a trunked system talkgroup. However you have a conventional Frequency set as a priority channel and you have Priority Scan Mode On and all the correct settings to do conventional priority scanning.
If the conventional frequency becomes active, the scanner jumps off the trunked system and listens to that active convention frequency that is a priority channel.
On the other hand, if the scanner is holding on a non-priority conventional frequency, the scanner does NOT look to any trunked systems to see if there is any activity on a trunked system, priority or otherwise.
I suspect and the manufacturer probably won't confirm because it may get into engineering stuff, but the way they go about checking for trunked activity, especially in multiple site systems, takes too long for priority scanning in trunked systems to be efficient.
