Let me start by correcting a few misconceptions.
That is a common misconception. Source compatibility is virtually impossible to maintain. By comparison, Binary compat is therefore infinitely easier to maintain than source compatibility. I explained all of this here: A Guide on Binary Compatibility - need your input! - #2 by sjrd. Fortunately, source compatibility is less important than binary compatibility, because it does not suffer from the dependency diamond problem. That also I explain in the mentioned post.
Another misconception. sbt-mima is just as capable at checking binary compatibility for Scala.js libraries as for JVM libraries. We made sure of that when designing Scala.js.
Uh!!? Scala.js cares about binary compatibility very much! In fact, I think the 0.6.x series come in second place for the longest streak of maintaining backward binary compatibility in terms of elapsed time (2.5+ years so far, after sbt 0.13.x which is 4 years in), and actually hold the record for the longest streak in terms of number of versions (21 binary compatible releases from 0.6.0 to the currently released 0.6.20).
OK, now my actual open ended answers.
I don’t think so. Scala.js and Scala Native both emit reasonable .class files that tools such as zinc can use. See my first post in this thread. This was designed as such since Scala.js 0.1 (I’m not kidding) so that all those tools would play nicely with Scala.js out of the box.
I very much doubt that. Sources in Scala are extremely volatile, due to some of its language features, most notably implicits. As I said earlier, maintaining source compatibility in Scala is not possible. Therefore dependency graphs based on source dependencies will break in horrifying ways, and nobody will be able to fix them.
Between source deps and @fommil’s suggestion of Scala.js mirrors everywhere, at the least the latter stands a chance, because it’s technically sound. The former isn’t.
This is an idea worth exploring, but it would require strong buy-in from sbt core. I won’t fight that fight, but if other people in the community are willing to, be my guest. Note however that there is a fundamental difference between switching the Scala major version versus switch the target, regardless of whether Scala.js is activated via a plugin or not. The former doesn’t change at all the set of defined settings and tasks. The latter, however, means that some settings and tasks are defined in some targets and not in others (obvious example: fastOptJS). This means that for example when you switch your project from Scala.js to Scala/JVM, if you have settings that read fastOptJS.value, your build breaks because the dependency graph cannot be built. This is fundamental.