This code does not belong in the managed connection pool. The pool is protected by a lock (the permits semaphore).
If the thread comes in a interrupted it can be assumed it should not be attempting to use more resources.
Your bug report shows where the thread's interrupted status is not what you expected. It has been interrupted because the suspended transaction (on the same thread) timed out.
IMHO, the exception should be thrown if the transaction is trying to get access to managed resources after a transaction timeout. The issue is what todo about other contexts on the thread not associated with the timed out transaction, i.e. the equivalent of RequiresNew or NotSupported ejb invocations.