Maybe something where hints or comments could be leveraged or expanded as well? For example, many customers I've interacted with have use-cases where they are submitting queries for reports or similar and for these queries, the customers do not care much about how long the query takes, just that the query completes successfully. It would be helpful to enable users/applications to provide hints or similar data to MaxScale to indicate when a query is explicitly low priority for completion time to enable MaxScale to make better QoS decisions as part of this feature.

A simple approach to this would be to add a new routing hint type that would prioritize the query that has it. Combining it with idle_session_pool_time, MaxScale could push the query to the front of the queue instead of adding it to the back where it normally would end up at.

That makes sense, but most customers I've talked to view this problem the opposite way. That isn't to say we shouldn't solve priority queries- we definitely have customers interested in those as well. But we should consider if there is anything else we can or should do for queries customers want to specifically mark as low priority.

If nothing else, explicitly low priority queries could be held up to x (ideally configurable) time before being put into routing algorithms when idle_session_pool_time is in-use and concurrent client connections/queries to MaxScale have (on average, or similar stat) exceeded available backend connections (aka the sum of backends' max_routing_connections for a router).

Could also consider something like expanding on ADAPTIVE_ROUTING where explicitly low-priority queries can withhold being submitted to a backend until a backend's load/latency drops below a (configurable) metric.

Fwiw, I understand the priority queries markus makela described (which are good and which imo we should do), the max_routing_connections-observant de-prioritized queries, and the ADAPTIVE_ROUTING-aware de-prioritized queries are probably three, separate feature requests. I wouldn't have any issue tackling priority queries first and the two, de-prioritized query scenarios I brought up here separately (possibly with a later release target).

Could SQL syntax be used as hints? for example the WAIT syntax?

Combining some of the features from the topfilter and tpmfilter to show where the time is spent would help evaluate how well the filter is working.