Note changes in unicode escapes and case companion

_overviews/FAQ/index.md

@@ -139,6 +139,14 @@ REPL, but won't work in typical Scala 3 application code.
 For an alternative way to detect the Scala 3 version, see
 [this gist](https://gist.github.com/romanowski/de14691cab7340134e197419bc48919a).
 
+### I want to use Scala 3 but now a bunch of stuff just broke in my project. What's up with that?
+
+There is a [guide for migration](https://docs.scala-lang.org/scala3/guides/migration/compatibility-intro.html)
+that includes a [table of incompatibilities](https://docs.scala-lang.org/scala3/guides/migration/incompatibility-table.html).
+Incompatibilities are largely due to dropping old features and introducing new ones,
+rather than subtle changes in existing features.
+The migration guide provides strategies for either migrating to new syntax or maintaining cross-compatibility.
+
 ### Why is my (abstract or overridden) `val` null?
 
 <!-- this is left over from a previous version of the FAQ.

_overviews/scala3-migration/incompat-other-changes.md

@@ -166,6 +166,33 @@ fooCtr.tupled((2, false))
 ~~~
 {% endtab %}
 {% endtabs %}
+
+To assist migration, the compiler will insert the call to `apply` as needed:
+{% tabs scala-3-companion_3 %}
+{% tab 'Scala 3 Only' %}
+~~~ scala
+case class C(i: Int)
+List(42).map(C)
+case class D(i: Int, j: Int)
+List(42->27).map(D)
+~~~
+{% endtab %}
+{% endtabs %}
+
+In Scala 2.13.13, this behavior is enabled under `-Xsource:3cross`.
+That is, case companions that do not extend `Function` can be used as if they did,
+or equivalently, as though `apply` were inserted. However, since Scala 2 does not
+adapt `apply` for the tupled case, `tupled` is supported directly.
+{% tabs scala-3-companion_4 %}
+{% tab 'Scala 2 Only' %}
+~~~ scala
+case class C(i: Int); object C
+List(42).map(C)
+case class D(i: Int, j: Int); object D
+List(42->27).map(D.tupled)
+~~~
+{% endtab %}
+{% endtabs %}
 ## Explicit Call to `unapply`
 
 In Scala, case classes have an auto-generated extractor method, called `unapply` in their companion object.
@@ -325,4 +352,4 @@ In such case, we can use a wrapper class around `Foo`:
 
 -def g(foos: Seq[Foo[_]]): Unit
 +def g(foos: Seq[FooWrapper[_]]): Unit
-{% endhighlight %}
+{% endhighlight %}

_overviews/scala3-migration/incompat-syntactic.md

@@ -23,6 +23,7 @@ It is worth noting that most of the changes can be automatically handled during
 |[Wrong indentation](#wrong-indentation)||||
 |[`_` as a type parameter](#_-as-a-type-parameter)||||
 |[`+` and `-` as type parameters](#-and---as-type-parameters)||||
+|[Unicode escapes](incompat-syntactic.html#unicode-escapes)||||
 
 ## Restricted Keywords
 
@@ -237,3 +238,13 @@ The solution is to choose another valid identifier, for instance `T`.
 
 However, `+` and `-` still are valid type identifiers in general.
 You can write `type +`.
+
+## Unicode escapes
+
+Unicode escapes of the form `\u0061` are no longer natively supported in any position by the compiler.
+
+Instead, they processed like other escapes in string literals.
+This means, in particular, that they are not processed in "triple-quoted" strings or by the `raw` interpolator.
+
+In Scala 2, a deprecation is issued, but under `-Xsource:3cross`, the behavior is the same as Scala 3.
+

_overviews/scala3-migration/incompatibility-table.md

@@ -42,6 +42,7 @@ Some of the old syntax is not supported anymore.
 |[Wrong indentation](incompat-syntactic.html#wrong-indentation)||||
 |[`_` as a type parameter](incompat-syntactic.html#_-as-a-type-parameter)||||
 |[`+` and `-` as type parameters](incompat-syntactic.html#-and---as-type-parameters)||||
+|[Unicode escapes](incompat-syntactic.html#unicode-escapes)||||
 
 ### Dropped Features