eugene yokota

This would break the existing behavior where the build would function without any build files, which allows things like sbt new. Additionally not all sbt projects are Scala projects.

@soc As interesting as the idea of reducing Scala favoritism is, I think it's a whole different layer of discussion, so could you open a new issue or a thread...

It might be helpful to display some information about the subproject when sbt starts up or when the subproject is switched could help. Something like: ``` [info] current subproject is...

If we think about this as removal of having an implicit `scalaVersion`, maybe I should start displaying warnings.

The sin of sbt 1.x, is that it was released in 2017, and sbt 2.x hasn't been developed. sbt 1.x should keep the build semantics, which means defaulting to 2.12....

@dwijnand Updated the description. The latter, but there's some impact to Ivy locking as well.

The goal is both for performance improvement and consistency across multiple users. > Could dependency resolution be different for different users legitimately? Some users might have different resolvers because of...

> Wouldn't a more natural location be under project/, alongside build.properties? @nafg I think of `project/` as a space for metabuild, or something that affects the metabuild. If not `src/sbt`,...

How so? `project/Foo.scala` is a source code of the root project of the metabuild. `project/build.properties` affects the library dependency of the metabuild, which is the sbt itself's version.

Consider a (proper) build that exists on the `~/hello/`, and is a set of subprojects `root`, `app`, and `library`. If we say the lock files go to the `project/` then...