the current opt:l:none / default / method / project / classpath and -opt:inline-project / inline-global are too coarse-grained:

• l:none / l:default / l:method are probably ok
• l:method could include inlining of nested methods
• l:project / inline-project is the main problem, it has very limited practical use
  • it basically means "inline from compilation units only", which can be surprising under incremental compilation
  • "project" basically assumes a project is compiled in one single module
• l:classpath is ok to have; it should probably be renamed l:global
• what we really need is a way to specify what classpath elements to inline from
  • only within the same source file
  • any source file - not recommended, as this changes with incremental compilation
  • specific classpath elements (folders, jars)

for specifying folders / jars, we could implement some matching, e.g., *akka-actor*.jar, or *target/scala-*/classes.

we'd need to provide some sbt examples how to pass output directories (own module, other modules) and dependency jars to this new option.