FileZilla client simultaneous transfer limit and control command queuing

Clarify the documented limits for concurrent operations in the FileZilla client and how queuing is applied when those limits are reached.

The client is reported to allow a default maximum of simultaneous data transfers and to use a fixed thread pool for control connections. Behavior is said to differ between client and server editions, and server-side concurrency settings are not exposed in the standard UI. Latency under concurrency could also stem from network conditions rather than internal queuing.

What is the documented default maximum for simultaneous data transfers and how are additional transfers queued? Does the control connection thread pool size impose a separate limit on concurrent command processing, and is that limit independent of the transfer limit? How is queuing indicated in the client logs for transfers that exceed the limit?