A symbol table stores more than names
An object-file symbol table associates names with types, binding, visibility and sections. An undefined entry can represent a reference awaiting a definition. A defined value also needs context: in a relocatable file it can be a section offset rather than a final address.
Local symbols belong to their object file, so identical local names in other files need not conflict. Global symbols can participate in inter-file resolution. Source-language name lookup and binary symbol selection operate at different stages.
References: [1]
Binding rules have a particular scope
Under ELF static link-editing rules for combining relocatable files, duplicate global definitions are generally errors, while a global definition takes precedence over a weak one. Undefined weak references receive special treatment rather than authorizing arbitrary selection.
Dynamic lookup has its own order and object scope. The generic ELF ABI describes searching the executable and dependencies together with visibility constraints. Static binding priorities are not a complete algorithm for every runtime loader.
A matching name still needs a matching interface
Resolving a name and address does not establish agreement about layouts, arguments or interface versions. Symbol metadata supplies part of the linkage identity; ABI mismatches can still break a successfully loaded program.
Resolution selects a definition, whereas relocation calculates and encodes a reference using machine rules, addresses and addends. Undefined references, duplicate definitions and faulty fixups should therefore be diagnosed at their respective stages.