I think I may have found a behavior different from Qemu's system emulation and Arm's FVP, which is supposed to provide exact hardware behavior. The Qemu commit I am using is ed67b09529a564d2ceb242a7cb02613bbe0fa3ca from the tgt_arm_mte branch and the FVP is the freely available FVP_Base_RevC-2xAEMv8A from Arm's website.
The scenario: Application signs pointer 0xdeadbeef using the pacda instruction to obtain a new pointer 0xXYdeadbeef. Later, the application wants to generate a new PAC signature for 0xdeadbeef, but uses 0xXYdeadbeef as the address for the pacda instruction to generate pointer 0xABdeadbeef. Finally, the application wants to authenticate using the autda instruction using 0xABdeadbeef and the modifier used to generate that pointer.
Qemu behavior: The autda instruction succeeds and 0xdeadbeef is returned.
FVP behavior: The autda instruction fails, and an invalid pointer is returned. In order for the autda instruction to succeed, the pointer provided to the pacda instruction must have the upper bits set to zero.
Is this a bug, or are we not very concerned about corner cases like these?