Linux on external drive / UEFI

Either method will work, but there are some caveats and differences:

• Some EFIs "helpfully" remove inaccessible boot loaders from their NVRAM lists of boot loaders. If yours is one of those, and if you put a boot loader that's to be launched directly from the firmware on your removable disk, its entry will disappear if you ever boot the computer with the external disk unplugged. This is obviously undesirable, but it may not be important if you only launch boot loaders stored on that disk from another boot program stored on the first disk (like GRUB or rEFInd).
• If you want to move the external disk between computers and boot it on multiple computers, you'll want to have an ESP on the external disk. In this case, I'd recommend storing your boot loader, or at least a copy of it, as EFI/BOOT/bootx64.efi on the external ESP. This way, the target computer will probably pick it up and give you the option of booting it from its built-in boot manager. (This trick can also be helpful in overcoming the problem identified in the previous bullet point.)
• If you move the drive around and manage to boot it on a secondary computer even without an ESP (as can be done with rEFInd, for example), an /etc/fstab entry pointing to the ESP on the primary computer will probably not work. This will most likely be a harmless failure, but you may see complaints about the missing partition. The worst-case scenario might be if it does work (say, because you refer to the ESP by device filename, like /dev/sda1) and if you run a software update that tries to update GRUB; that could cause severe problems on the secondary computer.

Overall, I'd say you should consider how you intend to use the disk (always plugged into one computer, plugged in sometimes but never used on another machine, or as a roaming OS installation used on multiple machines) and what sort of boot loader configuration you want (a single GRUB or the like that boots everything, a boot manager that boots a separate boot loader for each OS or distribution, using the machine's built-in boot manager to launch a boot loader for each OS, etc.). Once you've decided on these factors, the advantages and disadvantages of using a separate ESP on the external disk will become clearer. In many cases the differences will be small to nonexistent.

You're seeing a bug, and it's almost certainly not related to Secure Boot. I have several suggestions, but none is guaranteed to fix the problem:

• Update your firmware -- If the bug is in the firmware, updating it may fix the problem. Check with the computer's (or motherboard's) manufacturer to find updates. (They're probably called "BIOS updates," although technically your firmware is not a BIOS.) After the update, reboot into Linux and try again.
• Reset your firmware to its default settings -- Sometimes EFI boot manager lists become corrupted, causing symptoms like those you describe. Resetting all the firmware settings to their defaults in the setup utility may fix this problem. Unfortunately, this step will remove any working boot manager entries, so you may need to use an emergency tool (such as my rEFInd boot manager on a USB drive or CD-R) to boot until you re-create your working entries.
• Delete unused boot manager entries -- Deleting unused boot manager entries (with the -B option to efibootmgr) can also work around corrupted entries. Try efibootmgr alone, or efibootmgr -v for more verbose output, to locate duplicate or unwanted entries. (Note that the firmware may re-create some automatically when you reboot. This may happen with network boot options or options to boot external media, for instance.)
• Use another tool to create the boot entry -- Sometimes efibootmgr doesn't work but a tool in another OS (like bcdedit or EasyUEFI in Windows) or the bcfg tool in an EFI shell will get the job done. Thus, you might try these tools instead of efibootmgr.
• Use a fallback filename -- The fallback filename (EFI/BOOT/bootx64.efi on x86-64 systems) can be used if nothing else is working; however, this filename will typically be the last one a computer tries to boot. Thus, if it's already booting via some other name (like the Windows boot loader, EFI/Microsoft/Boot/bootmgfw.efi), you may need to back that up, rename your desired boot manager/loader to the currently-booting default, and reconfigure the new boot loader to offer to boot the one it's masquerading as using its new name. This is a bit of a juggling act at best, and not all EFI boot loaders for Linux can chainload to another EFI program, so it may not work properly. (I don't recall offhand if SYSLINUX can chainload another EFI program.)
• Switch to BIOS/CSM/legacy booting -- Most EFIs provide a Compatibility Support Module (CSM), which enables them to boot BIOS-mode boot loaders. Thus, you can install a BIOS-mode boot loader for Linux, activate the CSM, and boot in this way. If you're dual-booting another OS, though, you'll need to install its BIOS-mode boot loader, too, and this may necessitate changing from GPT to MBR partitioning. Overall, this approach is likely to be a bit of a pain; but on some EFIs (mostly old ones from 2011 or thereabouts), it may be the best approach.
• Return the computer for a refund -- If all else fails, and if the computer is within its store return period, you can return it for one that works. In fact, I recommend this approach before either of the preceding two options, if possible. If you do this, be sure to contact the manufacturer to tell them why you returned the computer. EFIs have had serious bugs from Day One, and some manufacturers have been slow to fix them, in part because their customers never complain, so the manufacturers don't realize how serious the bugs are.