So back to the original motivation for bringing this up. Recall that a cluster was upgraded. Everything appeared to work fine, except that the definitions of the functions were slightly different enough to cause a fatal issue on restoring a dump from pg_dump.
Since pg_upgrade is now part of the core project, we need to make sure this is not possible or be much more insistent that the user needs to upgrade any extensions that require it.
I'm missing something here because I do not recall that level of detail being provided. The first email was simply an observation that the pg_upgraded version and the create extension version were different in the new cluster - which is working as designed (opinions of said design, at least right here and now, are immaterial).
From your piecemeal follow-on descriptions I do see that pg_dump seems to be involved - though a self-contained demonstration is not available that I can find. But so far as pg_dump is concerned it just needs to export the current version each database is running for a given extension, and pg_restore issue a CREATE EXTENSION for the same version when prompted. I presume it does this correctly but admittedly haven't checked. IOW, if pg_dump is failing here it is more likely its own bug and should be fixed rather than blame pg_upgrade. Or its pg_stat_statement's bug and it should be fixed.
In theory the procedure and requirements imposed by pg_upgrade here seem reasonable. Fewer moving parts during the upgrade is strictly better. The documentation was not clear on how things worked, and so its being cleaned up, but the how hasn't been shown yet to be a problem nor that simply running alter extension would be an appropriate solution for this single case let alone in general. Since running alter extension manually is simple constructing such a test case and proving that the alter extension at least works for it should be straight-forward.
Without that I cannot support changing the behavior or even saying that users must run alter extension manually to overcome a limitation in pg_upgrade. They should do so in order to keep their code base current and running supported code - but that is a judgement we've always left to the DBA, with the exception of strongly discouraging not updating to the newest point release and getting off unsupported major releases.
