In SBT, I can add `crossScalaVersions := Seq("2.12.0", "2.11")` and everything will be (more or less) automatically compiled and published for both Scala 2.11 and 2.12. That's not something a more generic build tool can ever really hope to achieve.
But, having to worry about minor version differences like this is a wholly unnecessary problem, and one that didn't really exist in the world that make comes from.
These days we build tools on top of tools to solve problems of our own making that just didn't exist 10 or 20 years ago. All the build tools, packaging tools, deployment tools, containers, blah blah blah. None of that crap is needed to deliver working software in the form of 1 statically linked binary + 1 text configuration file, which will suffice for any software in the world.
2.11 and 2.12 are major Scala versions. Current minor version is 2.12.4
People have come to expect that minor versions are interchangeable (modulo fixes for clear regressions and changes made in reaction to important outside events like major releases of Java).
It's unusual but not unique, see Python, Linux kernel, Postgres.
They are not, at least in Scala. See 2.12.x.
It's also unavoidable.
In theory, either the people doing the minor version releases need to worry about it, make conservative changes, thoroughly test those changes against a large amount of code, etc. - or the people consuming the minor version releases need to worry about it and do much of the same thing. Either way, build tools that can handle compiler versioning is a win.
In practice, both the people doing the minor version releases and the the larger codebases consuming those minor version releases need to worry about it. "fixes for clear regressions and changes made in reaction to important outside events" is already a giant caveat that will lead to breakage at times, and even the best teams will occasionally fail to meet expectations.
All I'm saying is that the situation is bad as-is, and it would be good to not make it any worse.