Both MS link.exe and GNU ld.bfd handle it this way; one can have multiple object files defining the same absolute symbols, as long as it defines it to the same value. But if there are multiple absolute symbols with differing values, it is treated as an error.
As a general related note - LLD differs from link.exe (and GNU ld.bfd) when it comes to conflicts between a defined absolute regular and defined regular; LLD silently accepts these (in both orders), while both link.exe and ld.bfd error out on it.
This looks like the code that makes LLD not report duplicates between absolute and regular symbols. Should we re-evaluate that decision?
The logic dates back to 79a5e6b1b77efe7770503ebce2a808f0b89d9e50, which doesn't explicitly mention this case. That makes me think this behavior is not intentional, and we can change it.