Add documentation on planned inline changes.

^KT-64570

docs/inlining/examples/inline-to-crossinline.md

@@ -0,0 +1,46 @@
+# Why is JVM model simpler than klib? 
+
+Inline function have several more dimensions of declaration changes, compared to normal ones.
+- Type parameter can be converted between reified and not
+- Lambda paramerets can be inline/noinline/crossinline
+- inline keyword itself can be added/removed
+
+In klib compatibility model, we need to answer what happens in all these cases.
+
+In jvm compatibility mode, there are effectively no inline functions on link-time
+(except corner cases like [calling from java](calling-from-java.md) and [inline override](inline-override.md)).
+, but in that cases, inline functions already behaves as normal ones.
+So they can't be changed, and this makes mental model much easier.  
+
+For example, what this non-local return even mean, when `l` is `noinline`?
+
+```kotlin
+// MODULE: lib
+// FILE: lib.kt
+// version: v1
+inline fun foo(l: () -> Unit) {
+    l()
+}
+// version: v2
+inline fun foo(noinline l: () -> Unit) {
+    l()
+}
+
+// MODULE: other
+// FILE: other.kt
+// compile("lib:v1")
+fun test() {
+    foo {
+        return
+    }
+}
+
+
+// MODULE: app
+// compile("other")
+// compile("lib:v2")
+fun main() {
+    test() // Will it link?
+}
+```
+