Update: Here's a PR #7699

sbt-projectmatrix represents both the idea of Scala version cross building and platform cross building (JVM, JS, Native) as flat list of subprojects, allowing parallel building and accurate representation of partial Scala support (e.g. sbt plugin only available for 2.12). As convenient at times, the cross build could also bloat into building 12 = 4 x 3 (2.11 ~ 3, JVM, JS, Native) artifacts for each source change.

One way to solve this might be to implement a filtering mechanism, similar to Bazel query.
In Bazel, users can issue build or test command against a query like bazel test dir1/dir1a/.... This will test all test targets under dir1/dir1a/ directory.

... as glob

Since sbt doesn't use directory structure to represent subprojects, it would probably be useful to support ... as glob * of the subproject id.

$ sbt query compilerBridge...
compilerBridge2_10
compilerBridge2_11
compilerBridge2_12
compilerBridge2_13

?scala=3, ?scala=2.x, ?scala=2.13

Scala version filtering would be useful to have.
? denotes query pairs. scala as query would be used to query against scalaVersion setting of the subproject, but with special version handling.
3 would be interpreted as 3.x, which means any Scala version with first segment 3, including pre-releases.
2.13 would be interpreted as 2.13.x would means any Scala version with second segment 2.13, including pre-releases.

$ sbt query compilerBridge...?scala=2.13
compilerBridge2_13

?platform=jvm, ?platform=js, ?platform=native

Another useful filtering might be platform cross building.

$ sbt query ...
scopt
scopt3
scopt2_12
scoptJS
scoptJS3
scoptJS2_12

$ sbt query ...?platform=js
scoptJS
scoptJS3
scoptJS2_12

Query as an aggregate

Once we have the ability to filter down the list of subprojects, we could then use that as the mechanism of aggregation.
For example:

$ sbt qtest ...?platform=js

could test all subprojects that is Scala.JS.