This machine already runs two operating systems off one disk, sharing one EFI System Partition. Adding a third meant writing to that same shared partition and to the machine's live EFI boot configuration — real, hard-to-reverse changes on hardware two other working systems depend on, not a fresh disk with nothing to lose.
What was already there
Ubuntu and Manjaro each have their own subdirectory on the shared ESP (/EFI/Ubuntu/, /EFI/Manjaro/) and their own independent entry in the motherboard's EFI NVRAM boot menu — efibootmgr shows them as Boot0000 Ubuntu and Boot0001 Manjaro. Neither installation's GRUB setup touched the other's directory or NVRAM entry when it was installed; each is additive, coexisting on the same partition without needing to know about or reconfigure the other. Adding LFS as a third boot option meant following the same pattern deliberately, not improvising a new one: grub-install --bootloader-id=LFS, matching a scheme two working installs had already validated.
Following the book to the point where it says "don't"
LFS's own kernel chapter covers GRUB, but only briefly, and explicitly defers UEFI setups to a separate BLFS page rather than trying to cover both boot styles in one place. That's exactly what got followed here: LFS's chapter 10 GRUB section for the general shape of the step, BLFS's dedicated UEFI GRUB page for the actual mechanics, since this machine boots UEFI, not legacy BIOS. In UEFI mode, grub-install never touches the disk's MBR or partition table at all — its entire footprint is a new directory on the ESP's existing FAT32 filesystem and a new NVRAM entry, both additive by nature rather than by carefully-avoided side effect.
Backing up before touching shared, live state
Before running anything against the real ESP, it was backed up as a standalone step — not because a specific failure was expected, but because the partition in question is shared, live infrastructure two other operating systems depend on being able to boot from tomorrow. After the LFS-specific GRUB installation completed, Ubuntu's and Manjaro's own /EFI/ directories and NVRAM entries were explicitly diffed against their pre-change state and confirmed unchanged — not assumed unchanged because the process was additive in theory, verified unchanged because the whole point of a backup taken beforehand is to make that comparison possible afterward.
Hand-writing grub.cfg instead of letting a script find the other systems
The generated alternative — grub-mkconfig with os-prober — would normally scan every partition it can find for other operating systems and build boot entries for all of them automatically. From inside this build's chroot, doing that would mean scanning Ubuntu's and Manjaro's live filesystems as an incidental side effect of setting up an unrelated third system's bootloader. The actual grub.cfg here is hand-written instead, using BLFS's own template: a single menu entry for this system, a five-second timeout, nothing that reads from or reasons about the other two installs at all. Slower to write than letting a script do it, and deliberately narrower in scope than what that script would have produced.
The one thing that didn't go as planned
grub-install moved the new LFS entry to the front of the NVRAM boot order by default — not something the plan called for, and not something that was expected going in. It was flagged immediately rather than treated as acceptable collateral or silently left in place without comment. The actual decision, once flagged, was to leave the new order as-is rather than force the previous one back: GRUB's own five-second timeout on the hand-written grub.cfg already gives a real window to pick a different system at every single boot, regardless of which entry happens to be listed first. Noticing an unplanned side effect and deciding it doesn't need reversing is a different, more deliberate outcome than the side effect simply not being checked for in the first place.