In Fedora, it is allowed for compat packages to conflict with their non-compat equivalents. This is often necessary for compat -devel packages for things like unversioned soname symlinks, pkgconfig files, etc. It's fairly rare that relocated development files are supported by packages that need to build against those development files.

https://docs.fedoraproject.org/en-US/packaging-guidelines/Conflicts/#_compat_package_conflicts

In EPEL, we allow the same behavior between EPEL packages, but not between EPEL packages and RHEL packages.

https://docs.fedoraproject.org/en-US/epel/epel-policy/#conflicts_in_compat_packages

This policy includes the phrase "at this time", which has stuck out to me for a while. I didn't write it in the original policy, but I do agree with the sentiment that it is worth revisiting. I think it would be appropriate to allow EPEL compat -devel packages to conflict with RHEL -devel packages. As mentioned in the policy, EPEL has a greater need for this than Fedora does, yet we are severely limited by not being able to ship correct compat -devel packages when the corresponding non-compat package is in RHEL. EPEL's overall policy is that EPEL packages "enhance" the base distribution without "disturbing" or "replacing" packages from the base distribution. Most users do not install -devel packages, so they would not be disturbed by some -devel packages not being able to be installed at the same time. These compat package also have names that would be hard to mistake for the non-compat package. I've never heard of an instance of multiple conflicting -devel packages causing an issue in Fedora, or in EPEL (between EPEL packages). Most commonly these packages are installed during package builds of other software, which regular users can later consume without ever seeing the conflicts, because the corresponding compat library packages tend to be parallel installable and cause no disruption at all.