Is there a reason this isn't a whitelist + blacklist?

Defining whitelist as 'publish some / queue the rest', blacklist would mean 'queue some / publish the rest'.

Currently this operates only on name/e-mail combinations, and blacklisting these would be of little use as anonymous users can change them at any time. Even most spambots randomize their credentials, so it would filter only spammers more stupid than average bot.

I reckon there could be demand for this operating on name/e-mail/IP, name/IP combinations or IP only; the latter variant is where 'blacklist mode' would certainly make sense. I however have little idea how to implement switching as this relies heavily on primary keys. Maybe I should hold back the module until I figure this out.

(On a side note, I was surprised to learn I'm not by default subscribed to the issue queues of own projects – that's why it took so long for me to notice this.)

I think the blacklist would mean "never accept comments from this user" or maybe "behave as if comments are being accepted but actually delete them immediate.

So,
* whitelist - accept and publish immediately
* not on either list - queue
* blacklist - accept and delete immediately

Yeah?

(as I said on IRC) Yes, this makes sense.

I'm going to draw a development roadmap to see what what could I implement now* to make adding new features easier later.

* like, first of all, more specific naming of tables and variables;

not sure if it's OK to add tables/columns which are not used yet; IMO that's a bit unusual but I'd still prefer adding them before first release to writing updates later.

A simple IP-based blacklist is now added to 6.x-1.x-dev.

It however works not by 'accept and throw out' but by simply denying access to the comment form via hook_form_FORM_ID_alter().

Expect a new rc in a week or so.

Marking this as fixed; if someone has ideas / feature requests beyond this functionality, please start a new issue.