FAQ: what might be the problem with comment-related modules?

Actually the problem comes from core's comment module, which builds and reuse a comment_form in a way (I would say) isn't proper regarding usual FAPI flow.
From that point, many comment_form-related module attempt to make their own tweaks to deal with it. And the first assumption to make is: don't bother honoring a dummy form (which barely resembles an actual form).
That way many comment-related modules find a way to work (totally) around the comment_form, leaving slight opportunities to be compatible with other modules doing their own.
For instance:

• comment_upload states in its commented code when it is about to "rape" the comment_form #741544-9: comment_upload breaks on preview
• comment_bonus_api whips the whole form flow and jumps directly into comment_render phase making impossible to hook into the (no longer existing) comment_form flow.
  This particularly affects ajax_comments above 1.8 (not yet released) #722734-15: Compatibility with ajax comments

Does that mean that comment_driven won't support those comment_form-related modules?
It depends on whether the other involved party would like to work towards a mutual compatibility collaboration.

And why there is no problem with other modules which do change the comment_form?
There are some comment_form-related modules that are more respectfully regarding the form, and work in a non-aggressive fashion.
For instance:

• flatcomments only changes the parent id (pid) of the comment to force it to reply to the node instead of another comment
• comment_subject only alters the default value of the subject

And which of them does comment_driven belongs to?
Half and half.
It also "rapes" the comment_form, in the sense it builds a node_form and disguise the comment-related stuff within it.
But it does respect the flow of the form and gives everyone else the chance to do their own (i.e. weight=1000).
Moreover, if a 3rd party module brakes due to the unrecognizable comment-related stuff I'm open to support requests if achievable (which will depend on the approach taken by the other module or else the availability of its maintainers to go for it)