I'm not expecting XMP to work with Intel timings on an AMD motherboard, but AMD write AGESA firmware, and that includes speculative memory training.
At the moment, that memory training gives up on XMP timings far too easily because it doesn't loosen them enough. Even very loose 3600 timings and 1800 FCLK are waaaay better than JEDEC 2133 defaults.
Say you have a 3600 kit with 18-18-18-40 XMP timings that won't run on a typical Zen2 CPU; regardless of the board, the AGESA firmware will use the XMP primary timings and take a rough stab at the secondary timings before giving up. The thing is, XMP primary timings are almost always compatible with Zen2, it's the auto-generated secondary/tertiary timings that fail to boot on AMD and those aren't even part of the XMP spec. You can likely get that 3600-18-18-18-40 kit to run at 3600-16-16-16-36 on Zen2, so the problem is not the XMP data stored on the SPD.
IMO, AMD need to stick to the XMP frequency and voltage, and then use the primary timings as a reference point to calculate some safe values to attempt on the memory training runs. The best thing they could do at this point is hire 1usmus since his DRAM calculator works really well and is only a megabyte even as a compiled windows application with a GUI. If he can make a bootable timings calculator based off a handful of input variables, AMD can integrate the same kind of thing into AGESA. It doesn't even matter if AMD assumes low-quality RAM modules and runs a super-loose set of timings. Take that 3600 kit I mentioned above; Even if it was run at 20-20-20-55 timings with tRC of ~70 and tRFC of ~600 it would still be so much better than giving up and running the FCLK at 1066 instead of 1800 just because the memory training failed to find bootable values.