This also happens for SendingTime accuracy problem.

The error message is accurate but not particularly helpful. I've modified it to specify that an error has occurred before logon. However, the session does disconnect when these types of errors occur. I've added two unit tests to explicitly verify this behavior. It's also tested in the acceptance tests.

Is it possible that the client FIX engine is not recognizing the dropped connection?

The client recognizes the dropped connection. The problem is, that's all they get. There is not way for them to figure out what they did wrong without calling support on the other side and asking. For example, if someone tries to send a Logon message and forgets to include the password field, they get no error message back indicating that, just a dropped connection.

I have this problem with every new customer that first tries to integrate. They send their first Logon message, there's always some problem with it (SendingTime accuracy, missing Username, etc...), they get nothing, and generally assume it's a network problem, because they never received a single FIX message from us.

Hi, I have just tried this same scenario with QuickFix/J 1.4 and this is not true at least in our case:
Server is running QuickFix/J
Client sends a Logon message to the server with some field that does not belong to logon message
The server does not respond, and does not drop the connection.
If you look at the stack trace defined in the bug, nothing has really changed from what I can tell:
quickfix.Session.generateReject throws "Tried to send a reject while not logged on" SessionException which is caught by quickfix.mina.SingleThreadedEventHandlingStrategy$SessionMessageEvent.processMessage() which calls
LogUtil.logThrowable(quickfixSession.getSessionID(), e.getMessage(), e); and does not do anything else

How exactly does it disconnect????????