That is a spot-on definition of where I do NOT want to end up. Hooks everywhere and enormous extensions that break anytime we change anything in the core. It's not really clear that anybody is going to find that more maintainable than a straight fork, except to the extent that it enables the erstwhile forkers to shove some of their work onto the PG community.
Given the work over the last few major releases to make several other aspects of Postgres pluggable, how is implementing a pluggable protocol API any different?
To me, this sounds more like a philosophical disagreement with how people could potentially use Postgres than a technical one. My point is only that, using current PG functionality, I could equally write a pluggable storage interface for my Oracle and InnoDB data file readers/writers, which would similarly allow for the creation of a Postgres franken-Oracle by extension only.
I don't think anyone is asking for hooks for all the things I mentioned - a pluggable transaction manager, for example, doesn't make much sense. But, when it comes to having actually done this vs. posited about its usefulness, I'd say it has some merit and doesn't really introduce that much complexity or maintenance overhead to core - whether the extensions still work properly is up to the extension authors... isn't that the whole point of extensions?