The bug arise when using pg_dump with --disable-trigger option. The command just : pg_dump -f /tmp/test_disable_trigger.sql -a -b --disable-triggers -t some_table some_database
On the resulted script, it simply did
ALTER TABLE public.some_table DISABLE TRIGGER ALL;
COPY command
ALTER TABLE public.some_table ENABLE TRIGGER ALL;
This become a problem, when the destination table already has Disabled user triggers, it gets enabled by the dump script.
I would classify this as a limitation of the concept as opposed to a bug. I was going to say a bit more but I'm not that fluent with disabled triggers mode in dump/restore setups. I would advise using pg_restore and leaving the disable triggers option of the pg_dump command. It lacks sufficient information to write an appropriate script for an unknown target server.
If you have issues with pg_restore those would be more easily be deemed as bugs.
FWIW we have a "SET LOCAL" command that results in GUC variables being restored to their state post-transaction; we'd need a similar command for pg_dump to work properly.
It also altered another kind of trigger like Triggers firing on replica only, get altered to ordinary triggers.
This seems like a bug - though I'm not going to be confirming the behavior and you haven't provided evidence.