I do not know how you are looking up dns TXT values but I can assure you that the values shown in the thread are correct. See for yourself following the example below:
-> nslookup
server 96.235.134.178
Default server: 96.235.134.178
Address: 96.235.134.178#53
set type=TXT
_acme-challenge.floralencounters.com
Server: 96.235.134.178
Address: 96.235.134.178#53
_acme-challenge.floralencounters.com text = "R65NuuFu3k2IK18tOlJJ8Ii11ONlneBEFtaYa-Wa-Us"
That doesn't seem to be the case.
[unless the same server has multiple IPs]
In much the same way that I got them.
As a (unpaid) volunteer here, for more than four years, it should be obvious that I am more than happy to help. And although I've tried to answer your questions and, more so, point out where the problem seems to be, I am concerned that we aren't communicating well enough to "make progress".
Thank you for your help. The root cause of the problem I found because of a remark you made - the IP address for dns1.visualenc.com was incorrect in my domain registrar's records. Now that's fixed, things work.
All that being said. LE code leaves a lot - actually one heck of a lot - to be desired. Error messages are nearly useless and the lifecycle used for DNS based domain validation is highly questionable. Other SSL providers - $$ required of course - make this much simpler. In particular, they do not reset the whole process when a problem occurs but allow re-tries. Good software is not nearly as finicky as LE. But I guess you get what you pay for.
Regards and again thank you.
Sorry that you ran into such troubles. The client software you are using (acme.sh) is neither authored nor officially endorsed by Let's Encrypt. I encourage you to leave the developer of the software (Neilpang) feedback regarding your experience.
Please note that the "Let's Encrypt" part of this whole operation is just the Certificate Authority which issues certificates through the ACME protocol: the ACME server. The user (i.e.: you) needs to use a so called ACME client to use the aformentioned ACME server. These ACME clients are NOT part of Let's Encrypt As @griffin already stated, the ACME clientacme.sh is not from nor endorsed by Let's Encrypt.
Please don't let your unfortunate experiences with acme.sh influence your general feelings towards Let's Encrypt.
Other ACME clients like certbot might be more to your liking, or not.. In that case there are still a lot more to choose from:
Fundamentally use of a client side shell script is a bad approach. Too little control over the execution environment and too many unknowns at play. One of the major reasons web based, which is to say browser client based applications are much easier to maintain and deploy than classic client-server. Next to no security either which means all the security code still has to exist on the server so one might as well put all the code there. The only good reason for client side code is to improve the user experience - performance and appearance in other words. B ut that comes at a price too. Javascript provides all sorts of capabilities and at least twice as many hazards. For this SSL certificate application, KISS principles should prevail. Here they do not which is probably one reason so much "help" is needed in forums.
@Mole2021 That would perhaps be a useful approach for a CA issuing a few hunderd of certificates per day.. But not feasable at all for the goal Let's Encrypt has set: certify the whole entire world wide web! Note that Let's Encrypt issues more than TWO MILLION certificates PER DAY See the stats:
The only way to reach that goal is automation. And frankly, the method you're employing here now by adding TXT records to your DNS manually, well, that's just not the way Let's Encrypt was intended. And therefore your experience might be not so good in the process. Note that some people install certbot without any issue, run the basic recommended command without any issue and have their site encrypted within 5 minutes, without any issue.
So your own ideas might indeed be good ideas for a certain CA, IMHO just not for Let's Encrypt and its goals.
One last recommendation that may improve your DNS resiliency:
You could make use of IP 96.235.134.179 as dns2.visualenc.com
[since dns2.visualenc.com via IP 96.235.134.180 is not currently useable]
EDIT: On second thought...
That would likely reintroduce the sync latency issue (seen between .178 and .179) and cause future DNS validations to fail.
The DNSes are still out-of-sync (by weeks it seems):
nslookup -q=soa floralencounters.com 96.235.134.178
serial = 2021061503
nslookup -q=soa floralencounters.com 96.235.134.179
serial = 2021032502
Thank you for your suggestion.
The 180 address will be used for dns2 soon - synchronizing BIND servers is a bit of a pain so while records were in flux it was much easier to just turn off DNS on the 180 host.
As 
See the stats: