While selecting unique passwords for each purpose is a great idea, in practice this rarely happens. Therefore many select passwords from a personal pool of passwords that are easily remembered. When authenticating into systems that are used infrequently it is very probable that a number of passwords from such pool are tried sequentially. Alternatively, failed passwords are very close to the actual password in case of a typo.

Since almost nobody describes the password policy in effect, including how rejected passwords are handled, should one start assuming that these are collected in a database that is sold to the highest bidder?

Is there an implementation guidance? What usually happens with a candidate password when this is rejected? Are they being logged, immediately discarded or left to hang around until garbage collected? Are failed password handling procedures part of any audited controls? It seems that there are plenty of implementation requirements and recommendations regarding how valid passwords should be handled, but vague regarding rejected password values. 

EDIT

I will try to list here the various implementations that log failed login security credentials in order to get a feel about how widespread this procedure is:

Content Management Systems:


Joomla via Login Failed Log plugin 


  This Small Plug-in collect logs about each failed login attempt of your Joomla site’s administrator and sends an email about each of those to the super administrator of the site with the username, password, ip address and error.


KPlaylist v1.3 and v1.4 - a free PHP system that makes your music collection available via the Internet. 


  is logging the usernames and passwords of failed login attempts in the apache error log


Drupal 5.x before version 5.19 and Drupal 6.x before version 6.13.


  When an anonymous user fails to login due to mistyping his username or password, and the page he is on contains a sortable table, the (incorrect) username and password are included in links on the table. If the user visits these links the password may then be leaked to external sites via the HTTP referrer.


Standalone software

Reporting Server included with Symantec Client Security 3.1 and SAV CE 10.1


  The administrator password for Symantec Reporting Server could be disclosed after a failed login attempt. 


Linux:

OpenSSH via modified auth-passwd.c; using PAM via overloading pam_sm_authenticate function

EDIT #2

It seems that there is a consensus, and recording the failed passwords or PINS is regarded as a serious/major security risk, nevertheless as far as I know, the following standards provide no guidance, audited procedure or controls that specifically address this risk:  


PCI-DSS: Passwords procedures addressed in 8.4. and 8.5.  (failed passwords are protected only during transmission; after validation not considered passwords, therefore not required to be protected)
FIPS140-2: Authentication addressed in 4.3 (life-cycle of failed authentication data only partially addressed) 


Logging the value of a failed password attempt (cleartext or otherwise) seems like a security anti-pattern. I've never seen a web app that does this, and I'm not aware of any default system services such as SSH that do either. As pointed out by @tylerl below, most systems simply log meta-information about an access attempt (e.g. username, time, perhaps IP address, etc.). 

Why This Should Be a Security Anti-Pattern

Offhand, I can think of three reasons why logging the value of a failed password attempt is a bad idea: 

1. User Typos

It's extremely common for people to mistype a password by one or two characters. Examining a log file of failed attempts would make many of these easy to figure out, especially if you could contrast a sequence of failed attempts with a successful auth.

2. Guess-and-Check

Many people have two-or-three passwords they cycle through for everything. Consequently, when they forget which password they used on a given site, they just cycle through all of them until they find a match. This would make it trivial to hack their accounts on other sites. 

3. Log Bloat

Storing failed passwords serves no useful purpose for the vast majority of authentication services in production today. While there may be some edge cases, for most people, storing this data is simply throwing away disk space. 

On Relevant Legislation / Standards

I don't know of any standards (PCI, HIPAA, etc.) that specifically address procedures for storing failed login attempts, but I think that granted the above facts a good legal argument could be made for why the same standards that apply to storing passwords in general should also apply to failed-password attempts as well. In other words, you could make a legal argument that a failed-password is still categorically a password, and as such it is subject to the same standards. 

While I'm certainly not a lawyer, I wouldn't want a judge to have to decide whether or not I was negligent or in violation of industry standards because failed passwords were stored in cleartext and consumers suffered the consequences. I don't think that would end with a favorable decision.  

I agree with the OP that it might be useful for the various standards bodies to address this issue specifically (if they indeed haven't already).  To that end, my suggestion would be to create a compliance standard of not storing the value of failed password attempts at all. 
