(No replies as yet, so I guess I will wait for the technical folks to see the OP, but in the meantime…)
Following on from my "bigger question" in the last paragraph above, I can think of three ways around the problem:-
1. As above, turn off relayd on the firewall, spin up a small(ish) VM running Nginx as a load balancer and have that deal with all the certificates for all LBed sites.
2. Leave relayd running and temporarily make the pool 1 server deep when creating/renewing certs.
3. Make /.well-known an NFS share from a "master" within the pool, and mount it on all the pool members.
I see 2. as being a stupid solution and I'm going to discount it immediately (it's an obvious answer, but manually managing a pool like that scares the bejesus outta me, and doing it automatically brings me out in a cold sweat).
Technically, 3. intrigues me, but I really don't know NFS at all. Is this feasible from a "lag" standpoint - will it operate fast enough for letsencrypt to be happy? All the VMs are on the same host, the "network" between them is 4 x 1Gb. By the same token, it could be a gluster brick (but again, I have no direct knowledge of gluster - just repeating something I've just read in the Safari copy of the High Performance Drupal book)... EDIT I'm throwing a little glusterfs lab setup together and will have a play.
Finally 1. is the first thing that came to mind, and would answer the problem by moving the target to the LB (which is the most sensible place for it to reside in this situation, from what I've read), but again, this feels "klunky" to me; it's reinventing the wheel (not that we all likely haven't done that before now).
Any and all opinions welcomed at this juncture.