If we add a new executor node then that's something that the server will send to the client. The client does not need knowledge about which version of PostreSQL it is connected to. If it receives details about some new node type in an EXPLAIN then it can be fairly certain that the server supports that node type.
The above is basically how I imagine explain handling software works today - if it sees a specific structure in the output it processes it. It has zero expectations about whether a feature with a option knob is set to true or false. And its deals with the one non-boolean option by examining the output text.
What we're talking about here is the opposite direction. The client is sending the command to the server, and the command it'll need to send is going to have to be specific to the server version. Now perhaps all such tools already have good infrastructure to change behaviour based on version, after all, these tools do also tend to query catalogue tables from time to time and those change between versions.
I don't see how adding these optional GUCs impacts that materially. If the client provides a custom UI to the user and then writes an explain command itself it will need to possibly understand version differences whether these GUCs exist or not.
To hammer the point home if that client software is memorizing the choices made for the various options and then conditions its output based upon those choices then it should be specifying every one of them explicitly, in which case the GUCs wouldn't matter. If it is somehow depending upon the existing defaults and user choices to figure out the option values then, yes, the GUCs would be hidden information that may possibly confuse it if, say, a user has a GUC BUFFERS on but didn't make a choice in the client UI which defaulted to FALSE mimicking our default and because the default was chosen didn't output BUFFER off but left the option unspecified and now the buffers appear, which it for some reason isn't expecting and thus blows up. I could care less about that client and certainly wouldn't let its possible existence hold me back from adding a feature that bare-bones client users who send their own explain queries would find useful.
