1. Yes, the idea is to figure out the best solution and go with it (or
decide to do nothing).  That many possibilities exist just points to the
need for experience and wisdom in identifying the best choice ("one and
preferably only one").  One of the attractive points about Python is it
comes with so many such decisions already wisely made.  The design
wisdom embodied in Python is almost like a useful software library in
its own right.  So the presence of multiple choices should be seen as an
invitation to resolve the issue, not a flag to keep it unresolved.

2. I agree that the multi-arg and iterator API's should have been done
as separate functions (or denoted through a keyword arg), but what we
have isn't too bad, and it's what we have.

3.  min(iterable, key=f, start=x) should obviously default to the same
thing as min([x], key=f).  min(*args, start=x) should only be allowed
when len(args)==1, since the start arg is restricted to the case of
minimum over an iterator.  min(start=x) should not be allowed.

4. I'm in general unpersuaded by the argument that a stdlib function
isn't worth having because the same thing can be done by bloating up the
user code.  Python code should be concise, which means using the stdlib
in preference to writing more user-defined functions that the next
maintainer has to figure out, and which may have their own bugs and
unhandled edge cases.  For stdlib design, it's mostly a matter of
deciding whether a construction occurs often enough to write a re-usable
function for.  In this case it wouldn't have occurred to me to write any
of those suggested versions, instead of writing reduce(max, iterator, 0)
with an explanatory comment.  But even the observation that "reduce"
made me bloat up the comments in the code, rather than the code itself,
was enough to get me to suggest adding the initial arg.

5. I don't think it's good to rely on bool(seq) or len(seq) to be
available if there's a simple construction (like here) that works for
arbitrary iterables.  It's better to handle the general case.  I hadn't
even realized til just now that "sequence" and "iterable" didn't mean
the same thing.

6. Yes, I know it's not common to trap ValueErrors when using max with
iterables.  I wrote code without such traps myself and then got bitten
by unhandled exceptions when some of those iterables turned out to be
empty (hence my "reduce" hack).  It wouldn't surprise me if lots more
such code out there is similarly buggy.  I think it's good to make
bug-avoiding mechanisms obvious and convenient.