There is already a module that does the same thing

That is an alternative module, which anyway doesn't exist for Drupal 6.
An alternative to workflow-ng that runs on Drupal 6 should be Rules, but it has some issues to resolve, IMHO.

I am changing the title to better reflect the point.

Rules has the user interface for the conditions, and the user interface for the actions to take when the conditions are met.

What is the purpose to have this project, when there is already Rules? What does Condition(s) do that Rules doesn't?

I have no extensive experience with Rules but from what I've gathered, it does little besides extending triggers and actions. One of the many applications for it is actually to provide conditions for Rules. Another is providing conditions for block visibility, or to Views, as a filter handler. So I can definitely see a place for Condition(s).

Unless I am mistaken concerning Rules?

Rules allows the administrator to define some actions that are executed when some conditions are met.
Rules allows third-party modules to define new actions, new conditions, and new variables that are used for both the actions, and the conditions.
It's true that it allows to use the default actions Drupal 6 has, but that is only a part of the whole.

Definitively, I would say that Rules is a super-set of trigger and actions, because the trigger code present in Drupal allows to define when an action must be executed (when a node is being saved, when a node is being viewed, etc...), but not the conditions that must be verified (the content type of the node is ..., user has role ..., content is sticky, etc...).

But the most important part is that Rules allows to define some conditions that must be verified; Condition(s) allows to define the conditions, but it doesn't allow to define the actions.

The first screenshot shows the page that is presented after you create a rule, and select its name, and the event that is associated with the rule; the other two screenshots show the pages of a multistep form that allows to define the conditions associated with the actions of the rule. The conditions can be complex conditions as the content has type ... and (content is published or content is sticky).

That's well in line with my picture of how Rules works. :)

I have contacted fago, maintainer of Rules, to discuss how we could interact his module with a Conditions one. At the very least, with the architecture I have in mind, Conditions could expose its .. conditions, to Rules. Then other modules could define conditions only and have them used throughout a site. Geo, for example, could provide a user proximity condition, which could be used to only show a certain block if the current user is in the vicinity of Stockholm, or only send an email if a node is created in Sweden.

Good times to be had!

That makes sense. At least, Condition(s) would use the Rules user interface, without the need to create one itself; this would also allow the module to only have code for the conditions, which would make the code lighter.

I would rather change the name of the project that is a little confusing for the average user. I think that most of the people who read the project name simply think Conditions? I have already Rules; also, saying that the module offers some conditions makes people doubt of the real utility of the module, which is probably seen like a module for developers, and not a module for the normal user. The doubt they could have is also confirmed from the fact they don't see anything happen, when they install the module, and change the settings.

I would also like to see Conditions integrate with Rules.
I also see redundant functionality between this module and Ubercart's Conditional Actions.
It would be great to have one module that handles all conditional logic.

Any chance you folks could combine forces?