Big fat disclaimer: I work for Intel, but these thoughts are my own, and I have played no part in defining the UEFI specification. I'll be the first to admit t

Big fat disclaimer: I work for Intel, but these thoughts are my own, and I have played no part in defining the UEFI specification. I'll be the first to admit that the UEFI specification is not perfect - and I use it in my day-to-day work, so I feel like I have some room to complain about it. :) Some parts are under-specified, but the boot procedure is documented fairly clearly, at least by my reading. In particular, for OS installers, see section 3.4.1.1, "Removable Media Boot Behavior"; the default is to load \efi\boot\bootARCH.efi, where ARCH is ia32, x64, or arm. Notice that there is no mention of \EFI\Microsoft\Boot anywhere in the specification; that path is used internally by the Windows bootloader, but it also has a bootloader in the standard place on the install media. Each OS installer is expected to create an NVRAM variable pointing to the device path and filename of the bootloader for that OS; there's no hardcoded Windows-specific path or anything like that. Windows plays by the rules and creates a boot entry pointing to its bootloader; installers for other OSes can do the same. The firmware should provide a way to select from these boot entries on systems with multiple OSes installed. Now, whether the firmware actually implements the spec correctly is another question, of course... In reality, many implementations are indeed only tested against Windows, but that's no different than the state of affairs with the traditional PC BIOS. If the firmware has hard-coded checks for "Windows" or other special bootloader paths or names, it's a bug in the firmware, not a problem with UEFI itself. (Another small factual inaccuracy: traditional PC BIOS systems start up in 16-bit real mode, not "8-bit mode", but either way, it's not a pleasant programming environment; EFI's flat-mapped 32- or 64-bit mode with C-based APIs is heaven in comparison.)