First reaction is this seems like wiki material..

It may be, but there are other packages (mainly in the AUR) like memtest which bundle their own grub scripts and it's a nice convenience.

@darkbasic: Thanks for the ticket and suggestion.

We're quite intentionally not packaging the shell file in /boot (because frankly no package should own files in /boot, but that's another discussion).
If this snippet was to be added, I'm not even sure it would work out of the box, because for the binary to be used, the root filesystem would need to be unlocked (if the system is encrypted).
Have you tested your snippet on a system with full disk encryption?

From what I can tell, the only way this could work is by:
* providing a per shell (we have x64/x86_64 and ia32/x86, depending on the host's firmware architecture!) alpm hook [1] - in a non-active location from where the users need to symlink them to /etc/pacman.d/hooks/ - that copies the UEFI shell file to /boot
* providing a grub snippet (for UEFI shell(s) below /boot) - in a non-active location - from where the users need to symlink it to /etc/grub.d/

All of the above begs the question though, why we would only want to do this for grub, as there are other bootloaders around, too (e.g. systemd-boot [2], refind).
Providing a solution, that can be used bootloader agnostic (e.g. the alpm hook) and is not on by default, would be preferable.

[1] https://man.archlinux.org/man/alpm-hooks.5
[2] https://man.archlinux.org/man/systemd-boot.7
[3] https://www.rodsbooks.com/refind/

Every solutions has its pros and cons.

memtest86-efi (AUR) uses an alpm hook to copy the image to the EFI partition. It also creates grub/systemd-boot/whatever hooks depending on what's installed.

https://aur.archlinux.org/cgit/aur.git/tree/memtest86-efi-update.hook?h=memtest86-efi
https://aur.archlinux.org/cgit/aur.git/tree/memtest86-efi?h=memtest86-efi

I like this approach and I thought it would have been too cumbersome to be accepted in the main repo, but since you like it I'm all in for this because it works every single time (encrypted root, encrypted boot and whatever the bootloader).

I offered a simpler solution like the attached one because memtest86+-efi is packaged in the official arch repos and that's exactly what it does:
https://github.com/archlinux/svntogit-packages/blob/packages/memtest86%2B/trunk/60_memtest86%2B-efi

memtest86+-efi copies the image to the boot and loads it using the "linux" loader. Root being encrypted would not be a problem and the boot can be encrypted as well since grub is in charge to decrypt it.

Our problem is that we're using "chainloader" instead of the "linux" loader. That means that grub will fail to load it if you're using an encrypted boot (like me).

The solution would be to use the memtest86-efi approach: alpm hooks + copying the image to the EFI partition.

Let me know if the "alpm hooks + copying the image to the EFI partition" approach is good for you and how I should proceed: another attachment? Do you have a mirror repo where users can PR?

@darkbasic: Will look into it for the next iteration on the package.

@darkbasic: FWIW, the memtest86-efi libalpm hook would be fine, if we wouldn't have to duplicate the "find and mount ESP, copy to ESP" effort every time.

I'll need to think about how to best approach this, likely cross-package so that we only implement this once.