I don't think that's anywhere near a practical concern so it would be over-engineering and wasteful to do that.
You'll need entire new processor micro-architectures to use more bits from your 64-bit pointer. It's your hardware address bus that only supports 40- or 48-bits of address space, not your application or operating system. That's already 256 TB as well. I don't think you'll hit that limit any time soon.
I don't know. There are lots of applications for pointer tagging of some sort; and as far as I'm concerned, this authentication code is just another "tag". All the unused bits in a 64-bit pointer are great and plentiful until you realize you might not be the only one wanting to use them.
I, for one, would love it if we had hardware support for "fat" pointers with a portion dedicated purely for addressing (possibly with the ability to use the n low bits as tag bits in n-bit aligned access) and another portion dedicated for auxiliary information. Furthermore, there'd need to be some agreement on how these bits are allocated between different actors (user, compiler/jit, OS?).
Right now, I would very much like to utilize some of the 64 bits we have. But I'm afraid that 10 years later, my software would be "old and cranky and does crazy shit with pointers so it's not compatible with modern systems and you'd have to rewrite parts of it to get it to run.. good luck".
You'll need entire new processor micro-architectures to use more bits from your 64-bit pointer. It's your hardware address bus that only supports 40- or 48-bits of address space, not your application or operating system. That's already 256 TB as well. I don't think you'll hit that limit any time soon.