At a quick look, the XOR trick depends on there being an integral type large enough to hold the pointer type, and if there is it appears to be legal. A strictly conforming implementation apparently might not have a sufficiently large integral type, although I can't imagine anybody writing one.
The XOR trick is inherently implementation dependent, since it requires manipulating a pointer while it's an integer. I think it's fair to assume anyone using it is only using it on a machine with a sufficiently wide integral type.
What's not strictly conforming in my mind is performing any manipulation on the pointer while it's represented as an integer. However, you would be correct to point out that if reinterpret_cast< sufficient_int_type >( pointer ) gives me value X, and regardless of the shenanigans I pull with X, as long as I supply that exact same bit pattern X to reinterpret_cast< orig_ptr_type >( X ) I should get the original pointer back. And if round-tripping a pointer through an int back to a pointer is strictly conforming, then the XOR trick is strictly conforming too.
(At the risk of sounding like I'm shifting goal posts, I do know the C++11 standard tried to get some wording in there to support garbage collectors. I have no idea how that language reads against the XOR trick. I do know the XOR trick would confuse GC by hiding pointers from it though. As for whether GC could ever work out-of-the-box in real, non-trivial C++98 programs that have been around awhile, allow me to show you my deeply skeptical face. You pretty much need a C++11/14 program written in a more modern style.)
In any case, can we both agree that the XOR-pointers trick is a trick best left in the last millennium in most modern systems?
The extra pointer could be legally put into the padding by a sufficiently smart compiler, I believe.
I don't believe structure copies are guaranteed to copy padding.
It's also moot on most systems: If pointers have the strictest alignment of any type on a given platform, there will never be contiguous padding large enough to accommodate a pointer. The only cases I can think of where pointers don't share the strictest alignment are systems with 32 bit pointers, but require 64-bit alignment for double and/or long long. Surprisingly (or maybe not), 32-bit x86 only requires 4 byte alignment for double and long long.
So even if it was legal for the compiler to play games on you within the padding in a POD type, on most commercially viable systems you'll never have the padding you need in a contiguous field.
We're rather far into the "theoretically possible, but with such restrictions that nobody would bother."