Argh, damn, seems we both missed that the driver is returned there, sorry.

Seems also like some tests should be added.

The "fix" you do here is flaky actually.
The original problem that I fixed by splitting that cache into two fields was, if configuration gets changed.
And the same flakiness is in the change you added here.
You still clear both caches, but you return the driver from the global cache if one was found or otherwise the one from the thread-local cache otherwise.

That means that if you changed the cacheDriverPerThread configuration at some point, you might even have entries in both and then always return the global one, no matter what the config currently is.
And even if the config would be considered (which probably cannot really be done here), you still would only get one of the two drivers back.

The main question probably is, what is the use-case for returning the driver there to consider what the appropriate options are.
You could consider not returning the driver from that method (having a private variant for the clear-and-quit or just doing the clear there copied.
Or you could consider returning a spreading driver wrapper that contains both drivers if present and each call is fanned out to both if found.

The changes here should work properly as long as the option cacheDriverPerThread is not changed after a driver was created, so probably in most consumers out there, but nevertheless the race condition does exist.

Actually, even the clearCacheAndQuitDriver is flaky still even with the changes here, as it will only quit the global driver if in both, one was found.
With the spreading wrapper or with copying the clear code and quit both drivers this would be "fixed".

But then it also needs to be defined what actually should happen on clearCache and clearCacheAndQuitDriver.
Should the latter consider the current configuration and if so, what is the current configuration in that static context?
Should both operate on both if both are found?
What should both return?

These API were actually broken since long time ago when the thread-local cache was added in the case of config change.
My changes now just surfaced that there is also a conceptual problem in these cases. :-/

Btw. no, these methods are not just for for testing purposes as the reporter of the current problems assumed. They are documented ways to force Geb to create a new driver on next occasion: https://groovy.apache.org/geb/manual/current/#implicit-driver-management. It is just now a matter of interpretation of the documentation how these methods should work and what they should return if anything. Maybe it would indeed be best to just not return anything from those methods. :-/

I tried using CachingDriverFactory.clearCacheAndQuitDriver() in a cleanup() and with v8.0.0 the old browsers ran until the JVM shutdown. With v7 I never even got a new browser on the next test so v8 was definitely an improvement.
I tested this PR and it seems to fix the issue.
The question how to handle changes in configuration during a JVM is bigger topic I think.
Maybe we could enforce global or per-thread caching and not allow changes? Maybe a good topic for the mailing list.

With that also my initial fix could probably be reverted.
But I don't know whether that is a good idea, as it removes existing functionality, so projects that need both would need to split their tests into two test sets? 🤷‍♂️

Well it is two different configurations in a way. I think a lot broke back in v6 when the configuration per test was done away with.

"Maybe we could enforce global or per-thread caching and not allow changes? Maybe a good topic for the mailing list."
This probably wont work as we have tests that use both ways in the same class.