The uefi-menu support turns out to only have been adopted by a small number of devices - Juno and Mustang are the ones we've seen. In the early days of the hikey 6220, that UEFI also used the same mechanism. When the hikey 6220 firmware merged with the HiKey 960 firmware, there was a (large) change in UEFI behaviour. It moved away from an interactive UEFI using text based menus to a non-interactive UEFI which could just load Grub or AOSP.
We are currently assessing whether to retain the uefi-menu support for systems which output something like:
[1] Boot Menu
[2] Debian
[3] PXE NFS on 00:00:00:01
Start:
etc. on the serial console during boot. These systems need automation to select the right option and enter the number for that option before booting can proceed. It gets more complex because the menus also support adding new entries which *change* the ordering, so that the number changes. It is entirely possible for the above menu to lose [2] Debian but that does not create a gap, that *moves* PXE NFS up from selection 3 to selection 2. If this happens via a test job (which is also entirely possible), then the device is effectively bricked unless LAVA knows how to "read" the menu. It's a complex mechanism which, thankfully, not many people have to handle.
More typical now is a "static" UEFI which admins configure to load Grub etc and this is likely to be what you have on x86 devices. It is possible to interact with these UEFI implementations but that is via a full GUI usually, much like the old style BIOS, often using colours to indicate selections. That kind of GUI is impossible to drive over a serial connection (monochrome & line based) but, thankfully, the interaction only needs to be done by admins and test jobs can simply let UEFI do it's thing and interact with the next thing in line.