Hello,
I noticed a small issue/inconsistency with this implementation - when there is a fresh project with no disk cache at all (I manually removed the AC & CAS directories), the target/out/jvm/scala-3.6.2/some-name/compiler-bridge directory contains the actual bridge jar (not a symlink). However, if I remove the target directory and run the scalaCompilerBridgeBin task again, the compiler-bridge directory then contains a symlink to the CAS store.

Because of this, I've been experiencing some flaky tests in the Scala plugin - sometimes the jar is in the project directory, and other times it's in the CAS store. I can try to handle this flakiness, but do you think it's okay that this behavior isn't consistent?

In general how is the flakiness manifested? Do you have some code that's following the symlink? If we want this cached, I guess we can try to make symlink even for the first usage?

In the sbt-structure plugin, there are tests that check the compiler bridge jar location from the scalaCompilerBridgeBin task. Sometimes, for the first test in a class, it reports the jar location as something like.../v2/cas/sha256-7ad43c60ac9617fe6bf0e7706bae9dce2492d25bf4a3b7c18eb8e2b7593fbb0e-31929 and other times as .../target/out/jvm/scala-3.6.2/some-name/compiler-bridge/scala3-sbt-bridge-3.6.2.jar.

This likely depends on the test order, but I'm not entirely sure. Either way, this behavior is also reproducible in any project, not just in tests.

I guess we can try to make symlink even for the first usage

If you think it's technically reasonable, then it should fix the problem.

I've split this into a new issue - #8445