Why add "cdriven" prefix to all the names?

lets start with the project page's description

The reason for this module to be so compatible with node-related modules doing their tweaks is that it builds a node_form and passes it through its normal flow without taking care of what is doing each module, therefore maximizing compatibility.
The trade-off is that comment-related modules might require special support #746870: FAQ: what might be the problem with comment-related modules?

what this module does is taking a node_form + comment_form and build a merged form to handle both at the same time
then issues arise, like:
- node_form having a 'comment' property to indicate whether "Comment settings" on that node are "Disabled", "Read only" or "Read/Write" (with respective values of 0,1,2) while the comment_form has a 'comment' property which represent the comment's body
- similarly, node_form may have other properties with the same names of comment_form's properties ("name clashes"), and when 3rd party modules comes in it gets worse

this is documented in the code, where comment_driven_form_alter takes place,
check comment_driven.alter.inc near line 80:

  // prepare to merge node_form into comment_form
  // avoid name clashes
  // (e.g. 'comment' is the body in comment_form and the comment_settings in node_form)

this is just right before invoking _comment_driven_disguise_children

the trade-off, as mentioned above, is that some comment-related modules might brake,
some of them can be handled making this module aware
other modules might not be compatible at all (e.g. comment_bonus_api)
some might need to be aware each other (e.g. WYSIWYG #747616-2: Compatibility with WYSIWYG)
and luckily, some will be seamlessly compatible (e.g. notifications_team, after bibo's contribution)

the worst part being modules which are capable of handling nodes and comments (e.g. comment_upload, WYSIWYG, notifications, live) because they are prepared to make their tweaks on either a node_form or a comment_form but not to a form which is both at the same time,
therefore, a solution might exists, but depends on what the 3rd party module does (e.g. notifications is been the wiser so far, and comment_upload the nastier)

regarding the "live" module, it states in its project page:

Note that it has only been tested with Page and Story content types, and hence currently supported with. CCK support not included. For full support for your custom content types, or some complex validation you might want to hack into live.node.inc and the companion JS file.

cdriven certainly requires a "complex validation", since it acts on behalf of a node submission and a comment submission at the same time

if you want you can open an issue for "Compatibility with Live", I would check it then, but with that description and AJAX involved it is unlikely to be compatible
check what cdriven does on preview, and you'll notice that there is both a node preview and a comment preview at the same time (which even has exposed core's bugs on preview #716788 and other 3rd party modules' bugs #718824: follow up foreign issues)
it seems to me (without making any review) that "live" wouldn't handle so complex forms