And that is the viable option while avoiding using the ESP for the purpose.
Creating the XBOOTLDR partition maintains the separation; and should even work well with a system using BTRFS (if say EXT4 is used for the XBOOTLDR partition. Mind you, I’ve never tried it, but it still makes the better sense.
I really don’t see what your problem with having stuff on ESP is. 
I’d rather ask myself why should I be using GRUB. 
The space that could be used for other things and in the case of multiboot there are potential security concerns in that other OSs have access to the boot files.
This isnt a problem with ~things on the ESP~, but a problem when, for example, mounting the ESP to /boot.
A matter of convention, I imagine. Clearly there are other viable alternatives, whether it be systemd boot, rEFInd; even LILO, among others. My concern is mainly limited to the possibility of having Linux kernels and related files on a vfat filesystem; generally. I recall with some trepidation how fat32 has failed in past years for varying purposes.
There is only one reason why I don’t use Grub for my mobile devices e.g. Laptop:
When I boot from btrfs-snapshot with LUKS, GRUB process decrypts LUKS partition extremely slow when Kernels and initramfs are inside the encrypted partition.
That’s why I choose limine and Kernels and initramfses are stored in a limited unsafe FAT32. limine has the ability to check any file and boot config to prevent booting if they are fake or corrupted. Systemd-boot does not.
Unfortunately, every device, smart TVs, UEFI motherboards, … only support limited FAT32 as the worldwide standard filesystem for bootloaders.
Related: I needed to update a BIOS a few days ago; prepared an exfat USB with the new BIOS files, and booted, completely forgetting that the machine in question was seven years old and still required the USB to be formatted with fat32 to be recognised by the previous BIOS.
Duh!
You’re using fat32 too, so I don’t see how that makes it any different.
As you are aware, fat32 is required as the underlying filesystem of an ESP; with the exception of a MacOS system, which allows hfs+; it’s difficult to avoid that for UEFI boot files on an ESP. Linux kernels and related files are not as static as UEFI boot files (xxx.efi) tend to be, and are more prone to damage on vfat types such as fat12/16/32 than a native Linux filesystem.
The difference is clear enough.
I understand that it’s also possible to house UEFI boot files on filesystems other than fat32, but doing so would be greatly outside the bounds of convenience, considering the defaults of the UEFI standard(s).
You’re using fat32 too
Yes, because this is the spec of the ESP. There is no choice other than fat. But i would prefer to use it only for reading a 2 MB loader, instead or reading and writing kernels there. Statistically, the chance that something in this old and non-journaled filesystem breaks is smaller.
Well, good thing you can use GRUB then. 
You might want to extend that to include CSM. 