Correct… you have static mode (can’t be changed) or random (privacy) mode where the UID is random for each RF session. Basically the ISO chip selection process is usually obfuscated for you behind whatever driver or platform is involved. Only having direct hardware access to the reader chips would allow you to see that lower level process take place, and this is where the obviousness of how badly software stacks in general want to avoid the tricky business of dealing with multiple chips in the field at once… typically at some point one of the layers above the hardware reader chip simply picks the first one seen and rolls with that, ignoring all others.
In Android it will do all kinds of interrogations on the OS side before handing the tag object over to your app to do anything with. This is sometimes why scanning an Apex with your phone seems to take a second before it seems to do anything… but if you sniff the RF between you’ll see the phone OS going apeshit trying different things. One of those things is trying to select the well known NDEF AID for Type 4 chips. This all happens after the ISO chip select process has completed of course… I don’t think Android even has a way to handle or deal with mutiple chips in the field at once, even though the NFC reader chip hardware in the phones definitely do.
When the P71 chips shipped from NXP has its mifare emluator turned on, it does some tricks in the ISO selection process with ATAQ and SAK so the reader hardware is basically tricked into thinking it could be a mifare chip. I believe this will also change the ATR the reader calculates… but I’ve not bothered to test a P71 with emulation turned on vs a P71 without. I have definitely run into this on Android where I do a taginfo scan and see mifare data, but also global platform and other smartcard features in the full scan.
Those dirty tricks in the ISO selection process is basically why you could not necessarily write a Mifare emulator applet and just deploy it to the P71 after the fact… Just like ultralight and ntag chips, all Mifare commands are raw ISO level commands not ISO7816 APDU commands sent over ISO14443A… and all applets on chip must communicate using APDUs.
I will say that in theory you could potentially write a DESFire emluator applet that could emulate some of the features of DESFire… the file types for example… but I don’t think you could emulate the file management commands without special permissions. Basically there are APDUs for managing keys and files on a DESFire that do not involve first selecting an AID… and on a P71 this would mean you’d have to have a special “management applet” that is set to be the “default applet” on the chip, so basically it’s always automatically selected and running after ISO chip selection completes… then it would technically be possible to write a DESFire emulator that almost completely emulates DESFire features on a P71… but there would still be some gotchas like creating new files with arbitrary AIDs on chip from a management applet. This again is where the DESFire emulator support NXP can cook in as an option for the P71 is fundamentally different because it runs at a lower level in the chip OS.
What I do think is interesting though is you could theoretically deploy DESFire file emulators as applets and they could individually emulate specific application AIDs… so like an access control system that formats blank DESFire cards with like 3 different AIDs to do different things… you could possibly write emulators and deploy those 3 emulator applets to act like the file types expected and then run the card through enrollment. That could be theoretically possible.