As far as I know, those two features are independent of each other.
nativedisk is just one of the ways GRUB can access the disks. But if the firmware does not support accessing the disk where the chainloaded bootloader is located, then the chainloaded second bootloader would need to also include its own drivers... or else it might be incapable of continuing the boot process alone because it cannot access the disk it was loaded from without outside help. (If the second bootloader relies on GRUB's drivers, then that's not true chainloading, but more like being an add-on module for GRUB.)
Supporting chain-loading requires that GRUB can load the chained bootloader exactly the same way the firmware would have done it. In case of PC BIOS, it's a simple matter of copying the loaded code to a known memory address and jumping to it. In case of EFI, the EFI Boot Services will provide the necessary functionality: basically GRUB2 just tells the EFI firmware "please run this file instead of me" and the firmware does exactly that.
In other architectures, the firmware might do something in the process of loading GRUB that cannot be trivially undone. Or perhaps there has been no need to add chainloading support for some of the other architectures so far.
When implementing chain-loading for new architectures, you will need to know and replicate what the firmware would otherwise do. Typically, the firmware will give the bootloader some information about the hardware it's booting from. If you use GRUB's
nativedisk drivers to extend functionality beyond what the firmware can do, you may have a problem: if the firmware could not provide the necessary boot information, will your chainloading routine be able to provide meaningful replacements for whatever the chainloaded bootloader will need? All this will be very much platform-specific: it might be doable on one platform and impossible on another.