On second thoughts; this introduces an awkward footgun for queries that use these sinks in needing to import a specific library. Perhaps a better solution is to switch the config in question to a different dataflow instance?

What we have been doing recently is:

• Add any reusable code like abstract sinks or additional taint steps to a library (like XSS.qll). This should also contain the CSV models and the default implementations.
• Add configurations and other classes or predicates that should only be used from queries to a *Query.qll file (like XSSQuery.qll) that imports the previous library.

And then:

• Queries that need to use the configuration can import XSSQuery.qll.
• Libraries that need to reuse or redefine sinks or taint steps can import XSS.qll.
• The bidirectional import of XSS.qll can be added to ExternalFlow.qll without adding any configuration to the global scope.

Would this work for you?

So here XSS.qll doesn't define any CSV models; but it is imported by libraries that do (such as SpringHTTP.qll). And as part of the default definition of its sinks, it uses a TaintTracking2::Configuration; so that also becomes globally visible through the bidirectional import of SpringHTTP.qll.
My current fix is to move this config, along with the definition of the default sinks, to a separate file, currently XSSDefaults.qll but could be called XSSQuery.qll. However, then if a query imports XSS.qll but forgets to import XSSQuery.qll, then the sinks don't work.

Yes, now it looks better: importing only XSS<Query/Default>.qll in query files makes sense, and XSS.qll is safe to be imported in non-query files. There's a check failing though:

FAILURE: non-query qll files should not import files ending in 'Query.qll'

I think this check should ignore .qll files in the same directory as a .ql file.