PS: It dawned on me that if pg_dump had used server side code to generate its DDL, its complexity would drop.
Maybe, that remains to be seen. pg_dump needs to produce SQL that is suitable for the target database, not the source database.
First, pg_dump has some special needs in addressing how it creates tables, to be able to load the data BEFORE indexing, and constraining (lest you have to struggle with dependencies of FKs, etc etc)...
But version checking is interesting... Because I found no way to tell pg_dump what DB to target. The code I did see was checking what server options were available. (I clearly could have missed something)... But exactly how would that work? All it knows is who it is (pg_dump V14, for example. So the best case is that it ignores new things that would be in V15, V16 because it doesn't even know what to check for or what to do). Which, to me, makes it more of a side-effect than a feature, no?
And that if it used a server side solution, it gets an interesting "super power". In that even pg_dump V20 could dump a V21 db with V21 syntax enhancements. (I cannot say if that is desirable or not as I lack 20yrs of history here). Finally, the thoughts of implementing this change at this point, when it would impact anyone using the NEW version to dump an OLD version without the server side support... So that migration may never happen. Or only after the only supported DBs have the required server side functions...