Since 4.3BSD the inpcb database prevented so called port stealing. Assume
you got a server bound to 0.0.0.0:port. If you allow an other application
to bind to IPv4:port, you would allow the latter to steal packets from the
former. However, this constraint also worked in the opposite direction:
if you have a socket bound to IPv4:port, its existence prevents from
binding to 0.0.0.0:port. This constraint is explicitly documented in
TCP/IP Illustrated Vol. 2 Section 22.7 chapter SO_REUSEADDR Examples,
Example 6. This constraint doesn't make any practical sense to me. First,
it can be negated with use of SO_REUSEADDR. Second, no packet stealing
happens - the second socket can't steal anything from the original one.
This is definitely true for our modern inpcb database, where the exact
search is always tried first before wildcard search. My reading of 4.3BSD
in_pcblookup() seems to confirm that it would neither allow any stealing.
Maybe artifact of even earlier version?

Why break such an old constraint? Because after all the refactorings that
we made to our inpcb database, the port index is serving just to satisfy
this constraint and nothing else. Removal of the port index would not
only provide some immediate memory savings, but will make it much easier
to get the database from the single lock, allowing for better scalability
of multiple parallel connect(2) syscalls.

Why not break such an old constraint? To be fair, I can't imagine any
legit use of it. Any application that would rely on EADDRINUSE for this
specific case. If anybody has any ideas, please - speak up.