Another workaround to "merge" fact types:
1 -- Go through the Fact Type list and edit all of the duplicates to match the built-in (or preferred custom) Fact Type. As with Repository merging, match everything - name, abbreviation, usage, sentences, etc.
2 -- Do a GEDCOM or drag-n-drop to a new database.
3 -- In the new file, you'll find the Fact Type merges have taken place.
Here is another variation on the same theme. I don't use RM's standard, built-in census fact type. The reason is that there are some limitations that I don't like in the way RM handles multiple facts of the type for the same person. For example, multiple facts of the same type for the same person make it essentially impossible to make use of that fact type in People View or to do accurate searches (or markings and unmarkings for groups) against that fact type. So I have a fact type called 1850 Census that I use for the 1850 census, I have a fact type called 1860 Census that I use for the 1860, census, etc. This completely solves RM's problems with putting census facts into People View and RM's problems with searching for census facts.
Rather than changing thousands (maybe tens of thousands?) of census facts by hand, I ran an SQLite script developed by Tom to change all my census fact types as required. A data element that RM stores for each fact type is the GEDCOM tag that should be used for GEDCOM export - BIRT for the birth fact, DEAT for the death fact, CENS for the census fact, etc. So Tom's script maintained CENS as the GEDCOM tag for all my "yyyy Census" fact types. Therefore, if I wished to do so I could drag and drop my database and all the census fact types would be restored to default. That's because a drag and drop uses GEDCOM for data transfer to the new database. Or I could run another one of Tom's scripts to restore all my census fact types to default. I would probably do the latter because I'm so suspicious of what data might get lost in the GEDCOM used for a drag and drop.
Even though the GEDCOM tag to be used for GEDCOM export is stored in RM's Fact Type table, it is not visible or editable from RM's user interface. It might be dangerous to expose it to the user interface, but doing so could be very useful at times.