The current usage of a Scapegoat config has a few implications which may not be worth the complexity.
It extends the defaults of Compile scope, over time more and more x := (x in Compile).value will be added to shadow the real Compile configuration.
Because it's a configuration running it on test sources would require duplication of most machinery, which is why it's not supported yet. A few requests have been made though: #18, #136, (I also added this in a private fork).
The future of custom Configurations are uncertain https://eed3si9n.com/sbt-drop-custom-config/ in sbt 2. The only reason I see for scapegoat having it's own configuration is to enable running compile without scapegoat enabled. This needs some exploring whether the machinery can be altered to do this in a task rather than entire configuration.
SBT's built in support to set -Xplugin for compiler plugins is hard to use in the current way without cross polluting: #159
The current usage of a Scapegoat config has a few implications which may not be worth the complexity.
x := (x in Compile).valuewill be added to shadow the real Compile configuration.-Xpluginfor compiler plugins is hard to use in the current way without cross polluting: #159