Yeah, I know wildcards were coming, though likely will not make use of them for this particular case.
Definitely wouldn't want it pre-approved for other than the specific key that issued the challenge request. It'd more be for the purpose of being able to split the path - I'd still want to validate for the full a.b.c.d name - but the idea being that the validation domain hierarchy could be distinct from the actual service domain hierarchy.
In any case, in the circumstance that led to this thread - it was solely a short term diagnostic problem - the vast majority of the time it does work smoothly and my client validation requests only take 30-40 seconds to stabilize before I submit the go-ahead to validate. (It works well enough that I've hit up against the issuance limits on a number of occasions.)
In case you're interested, I'm using this for an internal lab environment for a large group of developers/testers/etc. where they need to be able to test with a variety of clients (such that using an internal CA is mostly impractical), but the devices/servers themselves are not available on the internet. I have them submit the signing requests through an internal management portal that validates ownership/control of the name by internal rules, and then submits the LE signing request on their behalf using DNS validation. Only real downside is the nature of the usage (lots of individual devices/VMs) - it doesn't lend itself to batching up the certs/using SANs, so I tend to hit up against the issuance limits if we've cycled through a bunch of test machine names too quickly. (Names tend to include product version numbers.)
I'm not familiar with option B you mention on 'pre flights checks'. Got a reference? Or are you just referring to using the staging servers?