Improve Clover behavior in case if a class with the same FQN/source path, but a different content is instrumented again or merged

In large Java projects some classes are frequently generated (javacc, antlr, velocity, etc.). One of the problems is that these generators frequently do not provide absolutely the same output file contents being run twice with absolutely the same input data (e.g. some methods placed in different order, some comments are slightly different, etc.). Such situations may lead to problems when measuring coverage with Clover. We observed problems in the following 2 use-cases:
1) if a java code generation of the same classes was invoked twice in the same build for some reason (typically happens due to a malformed ant scripts).
2) if a project was built independently on different hosts (case of distributed builds), and after that the Clover data from the hosts were merged together. (Yes, I know that this use case is out of recommended Clover usage scenarios).

The problem in use case (1) is that the coverage of the classes that were generated twice is (surprise, surprise!) zero.
The problem in use case (2) is that after merging the coverage of "differently" generated classes, the result is the coverage only from one host, but not a sum as we might expect.

I suppose (this paragraph is my guess only) that Clover treats source files as different even if they differ in one character, and instruments them twice. Coverage and test tracing data are correctly calculated and written, but only for one "version" of the file. But when merging the data, data for only one "version" of the file are taken into the account, possibly because Clover dose not anyhow expect that class with the same path and FQN has two coverage sections. This leads to the above problems: for use case (1) empty coverage is calculated, and for use case (2) only one "half" of the coverage is taken into account.

I understand that the described use cases may be something singular, that is, something Clover not guaranteed to handle properly. However, these problems frequently happen in large modern Java projects (such as Apache Software Foundation projects), and, what is even more important, they lead to problems that are very hard to diagnose because Clover does not anyhow indicate that something wrong is happening (no error/ warning).

So, this Issue is a request to make the life simpler in described situations. I see two possible ways how that can be done:
a) Provide an option like <clover-setup .... strict="true">, <clover-merge .... strict="true"> that would cause Clover to fail immediately just on attempt to instrument or merge data containing class with the same source path or FQN in the same clover registry.
b) Provide a way to merge coverage from all "versions" of the same file. I understand that this may be not possible in cases if the 2 versions of the class differ significantly, but in some cases such option may be helpful.

To implement at least (a) would be nice.