Could you please provide a little more context about the problem you’re having? For example, is this with Certbot, or some other client? (Although Certbot is popular, this forum covers everything Let’s Encrypt, including at least dozens of clients.)
The odds of support for these files happening is pretty much Zero. Like mod_perl, OpenResty brings in a lot of new custom directives, interpolates the text configuration with code blocks, and even changes how existing directives are processed. Correctly parsing those things would require an enormous development effort, and it would still get a lot of things wrong.
IMHO, the best way to handle this would be to run Certbot in standalone mode on a higher port -- such as 8081 via the --http-01-port=8081 command, then proxypass your traffic from /.well-known/acme_challenge/ onto the Certbot server.
You are right. Thanks for the correction. It's an internal parser, which makes support even less likely. The blocks are supposed to be ignored, so the OP's config file probably misses one of the regexes or parser tokens.
I think some of these are provably impossible to parse correctly in every case ("formally undecidable" in Gödel's phrasing). The developers may not have thought about what they were giving up by increasing the power and expressiveness of the configuration languages with actual executable code.
For example, you might be able to make a web server configuration which displays the answer to an unsolved math problem... by doing a potentially infinitely-long search to see if any number is a counterexample, from inside the web server configuration. The web server might take infinitely long to start up if there's no counterexample, and a configuration parser might also take infinitely long to parse the configuration in that case. [in practice the computer can't actually represent numbers larger than some practical memory limit and so it would eventually get some kind of integer overflow or out-of-memory behavior, but maybe inconceivably far in the future]
If you don't have recursion or unbounded loops, systems with variable assignment and substitution can still be decidable.
Although if you allow conditionals that refer to external I/O or anything else that's not determined in advance, it's infeasible to determine whether an arbitrary condition is never, sometimes, or always taken. (And even where you can determine that the theoretical answer is "sometimes", it's possible that the actual inputs will be such that the practical behavior will be either "never" or "always"!) I don't remember what existing parsers do about that problem!