That would be lovely, but 2 issues:

a) EPEL sig is still trying to come up with an exact overlapping policy. We know that it will say not to overlap with os or optional, but as to which additional channels on top of that we aren't sure.

b) It's not at all easy to create such a script as this, as new channels are added all the time, packages are added to channels, ability to see whats in all the channels is not there.

Now, it could be that we could just make something now that handles os and optional and add on to it later.
Contributions welcome for such a script. ;)

I strongly agree this would be nice to have and even if it just tested what was in the repositories on a frequent basis and raised flags about conflicts quickly it would be a big help.

So problem 1 is defining the channels that conflicts aren't allowed with. I have opinions about this but the EPEL community just needs to decide what it is. After that it is pretty easy to check from a machine that has access to the defined channels using a bit of repoquery magic. Or a database of protected packages can be generated there to use elsewhere for testing new or existing packages against.

For RHEL5 there is a FAQ entry:
https://fedoraproject.org/wiki/EPEL/FAQ#How_can_I_know_which_packages_are_part_of_RHEL.3F

From last discussion with EPEL is more possible that there will be EPEL and EPEL.fast. I guess there might appear same packages in different versions, so my request wouldn't make sense.

Ad contribution, I don't do python.

We are close to having this in place now. More news soon.

https://infrastructure.fedoraproject.org/repo/json/ has json files with all the packages and arches

This is now all done as pkgdb uses that json file to tell if something is already in RHEL.