1. The communication mechanism can be used more wide, than only for this purpose. We can introduce a SendInfoHook - and it can be used for any customer probes - memory, cpu, ...
Not sure if for CPU you can get any more insight than an external tool like top(1) will provide. For the memory, it might be indeed useful in some way (memory context inspection?)
CPU is probably nonsense - sorry - but there are more other possibilities, how to use it - simple checking some internal states of extensions without log processing or without gdb, etc
So there's certainly a space for generalization. Rename it as pg_backend_info()?
It is good name, so why not?
2. With your support for explain of nested queries we have all what we need for integration auto_explain to core.
Well, I don't quite see how that follows. What I'm really after is bringing instrumentation support to this, so that not only plan could be extracted, but also the rows/loops/times accumulated thus far during the query run.
It is possible, but not necessary step - but it is premature question in this moment
