Pretty much everything we need to diagnose the problem: DNS records, IP lookups, HTTP responses, packet routing info, and (for now) order/authz details, etc. Basically any and all “Network Engineering 101” troubleshooting steps to perform an actual investigation, whereas right now all we can do is say, “Yep, that sucks, something is misconfigured.”
Also, when domains are redacted, it’s impossible for us to know which code paths were executed and which rate limits actually apply. It basically full-stops any rigorous troubleshooting process.
Make sure your DNS and firewalls are properly set up for the ACME challenges. There are docs at https://caddyserver.com/v1/docs/automatic-https which explain what is needed.
If you can’t verify your setup manually for whatever good reasons, then automated checks will require some significant effort on your end, which are still not guaranteed to be accurate predictors. For that reason we don’t recommend this. But if you insist, you’ll need one or more (preferably multiple) external vantage points, or in other words, servers outside your site’s network (and preferably on a different provider and in a different region). They’ll need to run ACME servers. Then from each of the machines you want to validate, you’ll need to conduct an ACME transaction with each vantage point. This causes your ACME servers to perform authoritative DNS lookups for your domains and, depending on the challenge type, establish special TLS or HTTP connections with your machines (or none at all if using the DNS challenge). If all of that works and your own ACME servers can issue a certificate, then it is likely (but not guaranteed) that Let’s Encrypt will, too.
This gets even more tricky considering the nuances of individual DNS providers, which have different propagation times and other guarantees (or lack thereof).
That’s a lot of work for very little reward, so we recommend just making sure that your ports are configured properly and your DNS records, too.
No, since the context in which a request fails varies, and the context changes the error handling, and this is too difficult to configure manually.
Not always, depends on the rate limit: Rate Limits - Let's Encrypt
Always test with some staging environment, never with their production endpoint. That’s in our docs too. 
Yes and no. Caddy 2 doesn’t use env variables except for HOME or XDG_DATA_DIR (if set). But you can customize the storage location, of course. It’s just not via env vars.
This actually has nothing to do with Caddy. As our docs say, if the process exits with a status code of 1, don’t automatically restart. It’s up to however you are running the caddy process.
Again, this is in the documentation: GitHub - caddyserver/caddy: Fast and extensible multi-platform HTTP/1-2-3 web server with automatic HTTPS
Configures Caddy’s default storage module. A storage module defines how and where Caddy stores assets (such as TLS certificates).
Default: The local file system (caddy.storage.file_system). If XDG_DATA_HOME is set, then $XDG_DATA_HOME/caddy is the folder. Otherwise, $HOME/.local/share/caddy is the folder.
Hope this helps!