コミュニティ主導のScalaフォークというアイデアの浮上から１週間を経て，Shapelessライブラリの技術リーダであり，TypelevelのアクティブなメンバのひとりであるMiles Sabin氏が，ScalaコンパイラのフォークをTypelevelブログで発表した。その３日後には，Typesafeの共同創設者で，2013年に同社を離れたPaul Phillips氏が，自身のScalaコンパイラのフォークを発表している。
MilesはTypelevel版フォークを発表したブログ記事で，Typesafe版Scalaコンパイラの次期リリースに対する現行のロードマップを見たことがフォークの理由だと述べている。Java 8互換性と安定性を主眼とした，2016年初めという同社の目標はあまりにも消極的だ，というのだ。TypesafeがJVMベースのエンタープライズミドルウェア界で製品販売を行うエンティティであることを考えれば
理解はできる，としながらも， 氏は次のように述べている。
まったく理にかなっていますし，大多数のニーズは満たしていますが，その一方で，Scalaコミュニティの中核に位置する重要なグループが，そのニーズを完全には満たされずにいるのです。... ここTypelevelの傘の下にあつまったプロジェクトは，そのようなグループの典型的なものです。
これらの満たされないニーズに対応するためにMilesは，保守的フォーク
と題したTypesafe Scalaコンパイラのフォーク
を提案し，次のように述べている。
私たちは保守的フォークとして，Typesafe Scalaコンパイラからのマージ性を確保したいと考えています。その一番の目的は，プルリクエストをフィードして ... Typesafe Scalaコンパイラに修正を反映することです。目標にしているのは，数年前まで見られていたような，言語の進化ペースを維持することです。ただし今後はオプトインのプロセスを採用して，コミュニティによる優先順位の設定を行うつもりです。
Typelevelが発表した協力体制についてTypesafeが見落とすことはなかった。同社CEOのMartin Odersky氏はTypelevelのフォークを歓迎して，次のように返答している。
Scala言語とコンパイラの安定したメインブランチを，より先進的かつ実験的なブランチで補完するというこのモデルは，イノベータと業務利用者の両方のニーズに応えられるものだと思います。Typelevel関係者の，ブランチを標準Scalaとマージコンパチブルにするという意向，新機能の統合に対する極めてオープンな姿勢，およびそれらがScalaの将来のリリースで実現されることを保証する体制を，私たちは称賛します。
Typelevelの発表の３日後，Paul Phillips氏が自身のフォークを控えめに発表した。氏は2013年，Scalaコンパイラの設計に関する相容れない相違を理由に，Typesafeを離れている。比較的穏健なTypelebelのフォークとは対照的に，氏のフォークはより分裂的なもののようだ。プロジェクトのREADMEには，次のように記されている。
[ このフォークは]最終的にオリジナルに合流することを目的とするようなフォークではありません。Scalaのリーダシップそのものがそのコアテクノロジに忠実ではないように見えますし，Scalaプログラマが(実際に，あるいは潜在的に)払わなければならないものの総和は大きすぎます。それを内側から変えようとして，５年間やってきましたが，うまく行きませんでした。今度は外側からやってみようと思います。
しかしながら，氏がフォークを発表した理由は利他的な部分，すなわちTypelevelの活動を支援することにあるようなのだ。これについても，プロジェクトのREADMEで語られている。
この状態でコードを公開しようとは思いません。[Typesafe版Scala]よりもずっと先行しているというだけでは，自分の名前を入れたいと思うにはあまりにも不足なのです。ですが，Typelevelも現在，Scalaコンパイラをフォークして公開しています。そちらで私の開発結果を利用してもらう方が，まだよいのではないかと思っています。
相次ぐ発表は，コミュニティ内にある種の懸念を生み出すものと思われるが，Scalawags PodcastのメンバがTypelevelのフォークを取り上げたエピソード20とそれに対する反応は，概ね期待の持てるものだった。彼らはみなMilesが好き
で，その発表の論調と，Typesafeの対応には勇気付けられているという。