In the release blogpost you can read about potential runtime semantics errors in for-comprehension possible after making better-fors a stable feature and how 3.8.2 protects against them.
The next minor version is already cut-off, we can expect 3.8.3-RC1 later this week. Track https://contributors.scala-lang.org/ for updates about next version.
Take a quick 5‑minute survey that directly impacts Scala’s roadmap, libraries, and tooling. This short survey evaluates Scala adoption and usage among developers. Click the link and complete the survey now to help shape the future of Scala.
Scala Survey 2026 is brought to you by VirtusLab and Scala Center. https://virtuslab.typeform.com/ScalaSurvey2026
Reading through the example of the changed behavior, is the difference in the results due to a Map being returned by the for-comprehension, and so even though every element in the first map is iterated with, the result collapses to one value due to there being only one key used for all results?
Yes, thats correct.
In 3.8 we use Map.flatMap((k, v) => Map(42 -> 27).map(???)) directly so whole for-comprehension block result type is inferred as Map[Int, Int] which later is collapsed to Iterable[(Int, Int)] after the Map construction and deduplication of the keys.
In 3.7 it was Map.map( in @ (k, v) => Tuple3(in, x, f(x)).flatMap(Map(42 -> 27).map(???))
The intermiediete map producing Tuple3 was required to handle for comprehension which at this point resulted in collapsing to Iterable[Tuple3] which affects the inference of the next calls in the chain. Already after the first map we have Iterable instance, so the Map(42 -> 27) needs to be converted to Iterable inside the last flatMap block so Map is not constructed and keys are not deduplicated.
tl;dr
3.8: We have Map[K, V] => Map[K, V] => Iterable[(K, V)]
3.7: We have Map[K, V] => Iterable[((K, V), Int, (K, V)] => Iterable[(K, V)]