Few observations, just in case these points are not already known.
1) fq_codel purpose is to be used at the bottleneck point. Typically a router, an access point.
2) fq_codel is based on a stochastic hash. Multiple flows can collide in a hash bucket.
3) fq is implementing pacing, and is meant for end hosts. It was designed with performance in mind.
Codel was not added there, because it was not needed (see point 1)), and only adding wasting cpu cycles.
4) Most of end hosts can usually send much faster than the bottlenecks their TCP flow might reach.
5) BBR just reacts fine in the rare case the bottleneck is right at the host itself.
In other words, you can install fq on your laptop or typical linux device, then you can use BBR right now.
For the few people that absolutely want their Access Point being able to initiate its own TCP flows,
and these TCP flows might saturate the bottleneck,
we will add a fallback to TCP stack.
TCP stack will implement its own pacing when it detects FQ is not installed/used.
At a performance cost, but who cares really.