Cisco Firewall :: ASA 5585- TCP Syslog / Logging Permit-Host Down

We have a firewall service environment where logging is handled with UDP at the moment. Recently we have noticed that some messages get lost on the way to the server (Since the server doesn't seem to be under huge stress from syslog traffic). We decided to try sending the syslog via TCP. You can imagine my surprise when I enabled the "logging host <interface name> <server ip> tcp/1470" on an ASA Security context and find out that all the connections through that firewall are now being blocked. Granted, I could have checked the command reference for this specific command but I never even thought of the possibility of a logging command being able to stop all traffic on a firewall.
 
The TCP syslog connection failing was caused by a mismatched TCP port on the server which got corrected quickly. Even though I could now view log messages from the firewall in question in real time, the only message logged was the blocking of new connections with the following syslog message: "%ASA-3-201008: Disallowing new connections."
 
Here start my questions:
 
- New connections are supposed to be blocked when the the TCP Syslog server are not reachable. How is it possible that I am seeing the TCP syslog sent to the server and the ASA Security Context is still blocking the traffic? 
- I configured the "logging permit-host down" after I found the command and it supposedly should prevent the above problem/situation from happening. Yet after issuing this command on the Security Context in question, connections were still being blocked with the same syslog message. Why is this? 
- Eventually I changed the logging back to UDP. This yet again caused no change to the situation. All the customer connections were still being blocked. Why is this? 
- After all the above I removed all possible logging configurations from the Security Context. This had absolutely no effect on the situation either. 
- As a last measure I changed to the system context of the ASA and totally removed the syslog interface from the Security Context. This also had absolutely no effect on the situation. 
 
At the end I was forced to save the configuration on the ASAs Flash -memory, remove the Security Context, create the SC again, attach the interfaces again and load the configuration from the flash into the Security Context. This in the end corrected the problem. Seems to me this is some sort of bug since the syslog server was receiving the syslog messages from the SC but the ASA was still blocking all new connections. Even the command "logging permit-host down" command didn't wor or changing back to UDP.
 
It seems the Security Context in question just simply got stuck and continued blocking all connections even though in the end it didn't have ANY logging configurations on. Seems to me that this is quite a risky configuration if you are possibly facing cutting all traffic for hundreds of customers when the syslog connection is lost or the above situation happens and isn't corrected by any of the above measures we took (like the command "logging permit-host down" which is supposed to avoid this situation altogether).