This is a follow-up to Bug # 16492 which also links to a thread sent to -hackers back in 2018.
I'm firmly of the belief that the existing behavior of DROP relation IF EXISTS is flawed - it should not be an error if there is a namespace collision but the relkind of the existing relation doesn't match the relkind set by the DROP command.
Since our documentation fails to elaborate on any additional behavior, and uses the relkind in the description, our users (few as they may be) are rightly calling this a bug. I loosely believe that any behavior change in this area should not be back-patched thus for released versions this is a documentation bug. I have attached a patch to fix that bug.
In putting together the patch I noticed that the existing drop_if_exists regression tests exercise the DROP DOMAIN command. Out of curiosity I included that in my namespace testing and discovered that DROP DOMAIN thinks of itself as being a relation for purposes of IF EXISTS but DROP TABLE does not. I modified both DROP DOMAIN and the Glossary in response to this finding - though I suspect to find disagreement with my choice. I looked at pg_class for some guidance but a quick search for RELKIND_ (DOMAIN) and finding nothing decided I didn't know enough and figured to punt on any further exploration of this inconsistency.
The documentation and tests need to go in and be back-patched. After that happens I'll see whether and/or how to go about trying to get my PoV on the behavioral change committed.
David J.