I think you can avoid that issue if you look at things in the following way. At any given time, for a particular commit in the history of scalajson, you can choose to use the latest version of Scala that is supported by the versions of Scala.js and Scala Native that you use. Note that for that commit, you can always choose to upgrade Scala.js and Scala Native to a newer version, since it is a new commit and it will therefore be part of a new release. Therefore, for that commit, all platforms can be built with the same Scala version, and there is no need for an additional environment variable.
If, in the future, a new major (aka binary breaking) version of Scala Native comes out, and you’d like to back-publish scalajson for that version, you can come back the tagged commit of your release, switch the version of Scala Native, and rebuild and republish. Since the newer Scala Native should still support the older Scala version that you used at the time you made that release, you won’t have a problem with the Scala version either, in this scenario. (Note: I am not sure whether Scala Native actually has a policy of always keeping support for earlier versions of Scala. Scala.js has that policy: every new version of Scala.js is published for all the minor versions of Scala available at the time of that release, back to 2.10.2).
It seems to me that this strategy should work in your specific case. Did I miss something?