xPDO Persistent Connection Default Change in MODX 3.0 Leads to Connection Pool Exhaustion

The goal is to decide whether MODX should expose administrator‑configurable xPDO connection pool parameters, such as an idle timeout or maximum pool size, to mitigate intermittent 'Too many connections' errors observed under high traffic. In MODX Revolution 3.x the default connection mode switched to persistent PDO connections when the driver supports them, a change documented only in the upgrade notes. This shift removes the per‑request fresh connection model of MODX 2.x and leaves connection lifecycle control entirely to the PHP PDO extension and the MySQL server, which provides no built‑in idle timeout or recycling mechanism for persistent connections.

Should MODX add a system setting for an xPDO persistent connection idle timeout that respects MySQL's wait_timeout? Would exposing a configurable maximum pool size via a new setting improve stability without breaking existing custom scripts that assume a fresh PDO instance per request? Is reliance on MySQL wait_timeout and manual pool flushing sufficient, or does MODX need native connection pool management?