Is this possible (without sbt set ... on the command line or custom sbt commands), and if not should it be?

I don't think it is, and "should it be" is so philosophical. 😄 What's the real world use-case here? The current standard is backwards, because once you declare you're using libfoo v1.2.3, transitive dependency management means that users that compiled against v1.2.3 aren't going to run against v1.2.0 instead. The only exception to the rule is scala-library (and "experimental" scala-reflect) and that's only true because it's special-cased in sbt, and it's there for legacy reasons. So I don't see why this would be needed.

checking both directions as an approximation for source compat

@dwijnand see discussion at scalacenter/sbt-version-policy#71 — you'll see there that this business of using a bidirectional bincompat check as a proxy for source compatibility was new and surprising to me as well

(apparently that passage in https://docs.scala-lang.org/overviews/core/binary-compatibility-for-library-authors.html didn't stick in my head, though I must have read it at some point)

I agree with @eed3si9n's point, which I don't think I can see being addressed in that thread:

In that sense, checking for source compatibility is not difficult. You write unit tests all API points that you care about. If you have to change your existing unit tests either in the code invocation or the expected value, you've likely broken the source compatibility.

and about how restrictive forwards compatibility can be, for that 0.01% chance of a source incompatibility.