I am unsure what is the motivation in returning the last candidate, but

I suggest two following things:

1. Make "max-key" and "min-key" return the first max/min entry if there are several candidates.

This behavior seems more natural/convenient (to me), because in most cases you want to get first "winner".
(e.g. find the first biggest vector in a sequence) and less often you need to get the last entry – in those cases
you can do "reverse" before feeding a sequence to "max-key", thus it seems having "return first max" behavior more useful.

Line #4424 should have ">=" instead of ">".

2. Make "max-key" and "min-key" make warranty on order, which max/min entry will be returned (either first or last).

Line #4420 should say "Returns the x for which (k x), a number, is greatest. In case of several matches, the first max entry will be returned" or the same doc, but saying "the last max entry will returned".

Steve Miner
added a comment - 18/May/12 4:03 PM The current behavior matches the documentation so I wouldn't consider it a "defect". There doesn't seem to be a compelling reason to impose a tie-breaker rule on the implementation.