Hello David
This is expected behavior, and it is related to the use of 00 (in hexadecimal) for the AFI. This addressing scheme was designed for a much broader use, rather than just for ISIS. In this sense, the AFI plays an important role, informing routers about who owns the address space and how the rest of the NSAP should be interpreted.
00 is a reserved/undefined AFI within the ISO standard. It does not point to any public or private authority, nor is it considered a valid numbering plan. So, for the purposes of ISIS, it is a bad practice to use it because it can be interpreted in unpredictable ways by various vendors and platforms.
IOS-XR is generally stricter in its interpretation of protocols, due to its primary use within provider networks. When it sees the reserved/undefined values of 00 for the AFI, it strips those bytes completely, considering them unusable, and uses an area address of 02. IOS-XE on the other hand is not so strict, so it accepts the use of the 00 as the AFI, thus interpreting the command differently, and ultimately getting a different area ID. Since the Area IDs are different, the adjacency cannot form.
As far as I know there is no way to make IOS-XR recognize 00 as a legitimate AFI.
Now, having said all of this, 00 should never be used as the NET for use with IS-IS, exactly for the reasons shown by your experimentation. The use of 49 is almost universally adopted to ensure compatibility and predictable behavior across platforms and vendors.
I hope this has been helpful!
Laz