Is that challenge really published yet?

RFC 8555 quotations from the March 2019 revision. Boulder text from acme-divergences text

RFC 8.2 : If a server's initial validation query fails, the server SHOULD retry the query after some time, in order to account for delay in setting up responses such as DNS records or HTTP resources. The precise retry schedule is up to the server ...

Boulder: Boulder (LE's server software) does not implement the ability to retry challenges.

Further, from a letsencrypt community discussion, posted by an LE engineer in March 2019: The crux here is that this is a SHOULD in the RFC 2119 sense. Boulder elects not to support retries and the spec allows ACME servers to make this choice. ... I can’t remember when the notion of retrying challenges was introduced but it isn’t on our road map to implement.

So we really must heed the advice in RFC 8.2: Clients SHOULD NOT respond to challenges until they believe that the server's queries will succeed. Given that sewer is(?) mostly used with LE, and a premature response by sewer to LE will lead to a failure that can be retried only by starting the whole order over again, this should probably be treated as a MUST for us.

By and large, this is likely to be more of an issue when using dns-01 challenges with a service provider that has slow propagation of updates (perhaps only sometimes). But there could be uncontrolled (by the user) delays in publishing http-01 challenges as well, no?

June 2020 the essential core, unpropagated() is in the new-model API. Some details may still change, but the question is now when it will be ready, not if. Considering a generic version (for dns challenges) that queries whatever server(s) are identified as authoritative... but that may not work so well for the DNS providers that are most likely to need it, since the essence of anycast service is that you cannot know which physical DNS server you are querying, let alone which one(s) the ACME server(s) will query, nor how quickly the update propagates through the herd. (mm 2020-04-19)