I think in general maintainers would be better served by declaring Performance is a Feature earlier in their projects and rejecting contributions that add surface area to the API at the expense of throughput on the existing surface area.

Wrapping modules to expose additional functionality for a niche in a problem domain is tricky. You will end up with some code duplication and some predictability issues with your timelines, but the end result will be better for it.

Long ago someone convinced me that 'Strangling a Service' could also be applied to APIs. The base module should be as simple as possible but no simpler, and more esoteric features should be shunted off to another module. And then in the case when features are antagonistic to each other, they can live in parallel in separate wrappers.

The tricky part there is writing unit tests in the base to defend the negative space that these features fit into. This feature depends on an invariant in the base API that will break everything if merged.