After looking at the proposed patch and tests, I believe that this isn't really a bug but rather a missunderstanding of how the API is supposed to behave. The patch is effectively modifying the engine to remember that the application previously indicated that it was drained.This will, however, introduce race conditions since the engine can't actually know if the application is currently drained or simply was drained at some point in the past.
To understand the semantics, it helps to imagine an application that has implemented a message queue exposed via AMQP at both ends, with strict semantics regarding "emptiness". In such a scenario, you should be able to push a message onto the tail of the queue, verify that it is accepted, and then drain from the head of the queue and be guaranteed of receiving at least one message. With this patch you would no longer have that guarantee. You would have a race condition where the engine remembers the queue used to be empty and drains the credit even though there is a message to supply.
I believe the fix for the scenario is for the application to call drained more frequently, i.e. whenever it wakes up and there is positive credit on the link and no messages to send.