There are also segmentation differences. Only one copy of the read-only data and code (aka text) segments are mapped into all programs which load the library. However, each program instance gets its own unique pages of read-write data. Those pages are always located at a fixed offset from their code segment. That way, modern CPUs can execute PC-relative instructions to generate their addresses. The global data segments for a module are always located at a fixed offset relative to the code pages.

See ARMv8 `adrp` (address of PC-relative page), RISC-V `auipc` (add upper immediate to program counter), and x86-64 PC-relative addressing for some modern examples.

Then go backwards in time and see how ARMv7 does it (literal pools) and how some earlier RISCs did it (Itanium and Alpha global pointer aka "gp", PowerPC table-of-contents register).

You can load multiple pages in a single read operation, yes, and do less computation when trying to load/purge on a per-page basis (instead of a lookup table you just do a single addition)

Map the file into memory, but not actually load it, just set up the mapping and wait until it's used to pagefault it in.

That's what we did on the old swap based systems, on modern paged systems we don't read pages in untill there is a page fault, to do that efficiently we need to align page boundaries with disk block boundaries - elf (and coff before it) allowed you to do this while a.out doesn't