This is kind-of doable right now with eslint overrides config, eg:

module.exports = {
  parserOptions: { project: true },
  rules: { ... },
  overrides: [
    {
      // idk if this would 100% work but as an example...
      files: require('./tsconfig.eslint.json').includes,
      parserOptions: {
        project: ['./tsconfig.eslint.json'],
        tsconfigRootDir: __dirname,
      },
    },
  ],
}

This would cause ESLint to pass project: ['./tsconfig.eslint.json'] instead of project: true just for the files in question.

The complicated thing about allowing [true, "path"] we've got is that order-of-operations is... unclear.

The big wins from relative mode are:
a) config simplicity - no need to manually specify globs or whatever - it "just works"
b) performance - we will only load the tsconfigs required for the lint run - nothing more, nothing less.

(b) is big because it means when you do yarn eslint ./some/file.ts:

• on string[] config we'll load EVERY SINGLE PROJECT in order until we find the matching project
• on true config we'll just load the nearest tsconfig - simples.

But as soon as you introduce BOTH - we now have this confusing approach in the form of "when should we load what config?"
Do we respect the order of definition - eg [true. "path"] means we try relative first, then try "path"? Or do we hard-code an ordering?
This could impact (b) above because if you do ["path", true] then we'll always load and chec "path" before trying relative resolution - so bad perf!

Also with ["path", true] you might have weirdness in the form of "some files in this folder are checked relative, but other files are checked via "path"" - which makes things more complex to reason about.

I'm of two minds about this... I don't really love the idea. I think I'd need to see a solid usecase to be convinced it's a good idea to implement it.

Marking as evaluating community engagement. If anybody listening to this issue has a solid use case, please do post it!

I personally am much less excited about it now that EXPERIMENTAL_useProjectService is looking more and more like our long-term recommendation (#7350).

With our release of project services and the release of flat configs - I don't see much value in this.
We were already on the fence with this and it hasn't received too much community interaction in 1 year.
As such we are rejecting this proposal.