we're like 99% of the way there - just need to handle cache lifetime and we gucci

Overall this LGTM - so stamped

Before you land it - could you do a perf test just so we can update the docs with messaging around perf if we need to?

To test the perf I'd just use thetime tool against main then against your branch:

• git checkout main && yarn && time ./node_modules/.bin/eslint .
• git checkout parser-options-project-true && yarn && time ./node_modules/.bin/eslint .

You'll see a line like this:

./node_modules/.bin/eslint .  62.97s user 4.09s system 167% cpu 40.009 total

The first number is the one to compare.
I'd do a couple runs of each just to smooth any outlier slowness.

I'd expect this to be a little slower due to the lookup required for every file - but I think that with the caching you've built in it shouldn't be MUCH slower. For a big, deeply nested project they might find it has more of an impact.

If the difference is minuscule then I don't think we need to worry about any messaging, but if it's different enough one way or the other it's probably worth mentioning!

But this is why it'd be worth a test - just to see if it is actually different enough.

If you wanted you could go hog-ham and investigate the proper perf trace before and after:
#6366 (comment)

The thing that would be interesting to see would be the cost of thecreateParseSettings before and after as that's where your changes are.
Would be interesting to see the proper breakdown!