I also found a case where the same MetaCyc ID appeared twice on a single GO term, both as a narrowMatch xref and an un-typed ref. I would be good if the new check also flagged these types of case.

id: GO:0016805
name: dipeptidase activity
namespace: molecular_function
alt_id: GO:0102008
def: "Catalysis of the hydrolysis of a dipeptide." [https://www.ebi.ac.uk/merops/about/glossary.shtml#DIPEPTIDASE, PMID:19879002]
synonym: "cytosolic dipeptidase activity" NARROW []
xref: EC:3.4.13.-
xref: EC:3.4.13.18 {source="skos:narrowMatch"}
xref: EC:3.4.13.21 {source="skos:narrowMatch"}
xref: MetaCyc:3.4.13.18-RXN {source="skos:narrowMatch"}
xref: MetaCyc:3.4.13.18-RXN
xref: MetaCyc:3.4.13.21-RXN {source="skos:narrowMatch"}
is_a: GO:0008238 ! exopeptidase activity

There are 8 remaining cases causing the pull request to fail:

MetaCyc:BUTYRATE--COA-LIGASE-RXN,MetaCyc:,http://purl.obolibrary.org/obo/GO_0120515;http://purl.obolibrary.org/obo/GO_0031956
MetaCyc:NPGLUCAT-PWY,MetaCyc:,http://purl.obolibrary.org/obo/GO_0019595;http://purl.obolibrary.org/obo/GO_0061680
MetaCyc:RXN-9385,MetaCyc:,http://purl.obolibrary.org/obo/GO_0052754;http://purl.obolibrary.org/obo/GO_0043910
MetaCyc:RXN-8307,MetaCyc:,http://purl.obolibrary.org/obo/GO_0102654;http://purl.obolibrary.org/obo/GO_0102843
MetaCyc:RXN-10884,MetaCyc:,http://purl.obolibrary.org/obo/GO_0052625;http://purl.obolibrary.org/obo/GO_0102085
MetaCyc:RXN-10885,MetaCyc:,http://purl.obolibrary.org/obo/GO_0052627;http://purl.obolibrary.org/obo/GO_0102086
MetaCyc:RXN-10886,MetaCyc:,http://purl.obolibrary.org/obo/GO_0052626;http://purl.obolibrary.org/obo/GO_0102087
MetaCyc:RXN-10887,MetaCyc:,http://purl.obolibrary.org/obo/GO_0052628;http://purl.obolibrary.org/obo/GO_0102088

I will look into these and fix in #28503

Thanks @balhoff

For the first issue:
MetaCyc:BUTYRATE--COA-LIGASE-RXN, MetaCyc:,http://purl.obolibrary.org/obo/GO_0120515;http://purl.obolibrary.org/obo/GO_0031956

I don't see BUTYRATE--COA-LIGASE-RXN on GO:0031956.
Is that error a false positive, or is there some other issue there?

@sjm41 sorry! This is another example of the confusing automatic move of xrefs from obsolete terms to their replacements (planning to fix that soon). It's on GO:0047760.

OK, I've fixed 4 of the remaining cases. The other 4 will be fixed by the proposed merges in #28503

@balhoff I believe your associated PR should now complete.

BUT BEFORE YOU DO THAT (!), I am wondering if this check for the same MetaCyc/KEGG database xref could be extended to also check for any terms that share the same MetaCyc/KEGG definition xref? Is that possible? If so, would it work best to bundle it with this current check?
I'm not sure whether this will throw up any additional cases, but if it does, then they should be examined and fixed.

@sjm41 the current check does not compare definition xrefs. It would complicate the query to do both in one check, so I think we should make an issue to implement a one-to-one check for definition xrefs and tackle that after going ahead and merging this check. How does that sound?

Sounds good, thanks!

@sjm41 one direction of the check passes now ("one-to-one-xrefs-by-value") but the other direction ("one-to-one-xrefs-by-subject") still has many violations. I put both of these in the same PR. Should I split it up and get the first check merged?

Yes please, splitting them into two sounds like an excellent idea!
I make myself a ticket or two to look at the other violations... see #28526 and #28527