This is a good question - with the approach of zero-knowledge for the web app, where there is no data sent to the backend, it is not something that might happen automatically. However, there could be an option to offer an assistance when some specific error code is returned, in which case the user must give consent to send error information and the domain back to the server to attempt some extended diagnostics.
I remember thinking about that at one point, though the amount of actual mails about some errors returned by LE servers is actually quite low (possibly because of the way the process is structured). There could be some improvements made of course - for example sometimes it is quite clear that returned content is a HTML response and not the verification file, so there could be some explanation given along the lines of what’s wrong and what to check.
From server-side perspective there could be a more specific set of codes sent to assist with diagnostics and tell one problem from another without relying on the text of an error message itself. Additionally there are limitations I noticed time ago (though not sure if I submitted those at the time as an issue).
For example, if you call ‘new-reg’ with a key that is already registered, you cannot get a proper ‘reg’ resource URL. The 409 response returned in that case sends an ‘Access-Control-Expose-Headers’ header set to ‘Link, Reply-Nonce’. However, the ‘reg’ resource URL is sent in Location and Link does not seem to be present.
If I’m not mistaken, fixing this looked rather trivial when I checked it at the time (adding Location to Access-Control-Expose-Headers value in wfe/web-front-end.go and wfe/web-front-end_test.go or providing the Link header with that value), but perhaps there was a reason for this particular system behaviour?
NB: This is posted quite early in the morning, so if there are typos or odd parts in the post - those will be fixed later