Now I believe the only reason that the 34411A firmware will refuse to run on 34410A is: the 34410A bootloader at physical address 0x0060230c on the flash (loaded address 0xFFE0230E) is writing a magical word 0x235a to RAM 0x9000000A. This address is then checked by the main firmware (store compressed on the flash too, in two copies) and expecting 0xB643. If it reads 0x235A, the meter will hang with the Load 34410A Firmware message.
One can see the evil instruction (38 60 23 5a li r3,0x235a) in the bootloader by querying DIAG:PEEK? 4292879116 and DIAG:PEEK? 4292879118,(4292879118=0xFFE0230E). If someone is willing to remove the flash from the main board and change the 23 5A at offset 0x0060230E to B6 43 with a programmer, then the meter should accept 34411A firmware as well. Someone brave enough can also try DIAG:POKE 0xB643 into 0xFFE0230E. I'm not sure if DIAG:POKE can write to flash, as the implementation is just a memory assignment, so it may not do anything. Alternatively, instead of crafting a firmware update package with the checkModelNumber patched, one can try to craft a file that overwrites the bootloader and modify the 0x235A to 0xB643. I'm not sure how the firmware update works (yet?) but it doesn't sound easy.
I have only a L4411A so have little motivation (and capability) of looking into this deeper, but if anyone interested want a GHIDRA project to play with, I may send it.
Bonus:
L4411A> DIAG:PEEK:FIRM? 24,0,0
Elapsed Time Hours: 266.822
This seems to return the total powered on hours of the meter.
OT: I was looking all around in the code to find a backdoor to allow backup of the cal rom, but couldn't. Most accesses are done by a call to iiceeprom and I couldn't find if the memory is mapped somewhere so I can fish out data by DIAG:PEEK?. If someone does find one, please let me know.