bug#15157: join doesn't follow norms and dies instead of doing something useful w/duplicate options

[Linda Walsh]

join is inconsistent with other utils (like cut, for example) in how
it handles a specification of a switch value that has already been
set.

1) if a switch is set more than once with the same value, it
doesn't complain, but if the options differ, unlike utilities
like 'cut', the tool dies rather than taking the final
specification as what is meant.

ex:
   cut -d'<TAB>' -d: -f1 </etc/passwd
doesn't issue any errors.

But the same thing with join:
join -t'<TAB>' -t: -f1 /etc/passwd /etc/group
join: incompatible tabs

???  tabs?  they are field separators.

Historically, options specified on the command line take precedence
over options in an init/rc-file or in the ENV.  Many utils
in a build process build up command lines in pieces -- with the
expectation that later values take precedence, allowing for
higher level make files to set defaults, while allowing make's
in sub directories to override options set in a parent.

Defaulting to "fail", rather than proceed with latest input
data, is rarely useful for humans.  It's arguable whether or
not it is useful for machines in most cases.

In the past, unix utils have tried to do what the user meant
rather than deliberately playing "stupid" and pretending to have
no clue about what was likely expected.