Thanks for thinking this through.

@SethTisue what do you think?

I lean mildly against merging this, on the grounds that (as Som has already said in different words) it grows the matrix of possible flag combinations that we have to support, and for relatively little gain

but I do really mean the "mildly"

@SethTisue is nothing if not mild. I think a neutral opinion is in favor of the contributor, who must have reasons, unless @lrytz changes his mind.

It occurs to me to wonder if a build might be configured with the source features, but there is no effect until source 3. Who would do that? Oh, maybe features in common settings, but only certain subprojects are migrating.

I wonder if the plugin formerly known as tpolecat has an opinion about these settings.

Yeah, it's case-apply-copy-access in particular that we want to enable. It is doable with -Xsource:3 and silencing all the warnings, but that seemed a bit weird (needed 14 -Wconfs). The codebase is not (yet) on the path to Scala 3.

Maybe just add an alias -Ycase-apply-copy-access, which preserves the status quo and acknowledges that, in the context of not migrating, it's just a forking option that changes semantics of a language feature. I'm too lazy to check if other source features are also candidates; I wouldn't propose -Ysource-features that aliases them all, or why not.

As a middle ground, I could leave in the Conflicting compiler settings were detected warning which says -Xsource-features requires -Xsource:3. It can be silenced with -Wconf.

Normal people use -Xsource:3 when they want a Scala 3 feature for migration, but you can go ahead and use -Wconf to silence this warning and we won't tell anyone.