fixup! Update KEEP on Explicit backing fields feature

proposals/explicit-backing-fields.md

@@ -55,6 +55,8 @@ class SomeViewModel : ViewModel() {
   * [Grammar changes](#grammar-changes)
   * [Java interoperability](#java-interoperability)
   * [Reflection](#reflection)
+* [Risks](#risks)
+  * [Unintentionally exposing a field as a return value](#unintentionally-exposing-a-field-as-a-return-value)
 * [Future enhancements](#future-enhancements)
   * [Underscore operator in type parameters](#underscore-operator-in-type-parameters)
 
@@ -448,6 +450,32 @@ On JVM backing field can be obtained using [`javaField` extension](https://kotli
 There is no API in Reflection to check whether property has an explicit backing field or obtain any information about it.
 Adding such an API might be considered in [Future enhancements](#future-enhancements).
 
+## Risks
+
+### Unintentionally exposing a field as a return value
+
+The ability to call both a getter and a field with the same name depending on the context of call
+introduces a possible error with the unwanted exposing field value (where getter value was meant), 
+when property is returned in function, especially when function return type is omitted:
+
+```kotlin
+class MyViewModel {
+    val city = field.asStateFlow()
+        field = MutableStateFlow("")
+
+    fun updateAndReturn(newValue: String): StateFlow<String> {
+        city.value = newValue
+        return city // exposed MutableStateFlow instead of read-only wrapper
+    }
+
+    fun updateAndReturn2(newValue: String) /* MutableStateFlow inferred */ =
+        city.also { it.value = newValue }
+}
+```
+
+Although it would be nice to have warnings from the tooling in such cases, 
+it is unclear in which cases such behavior is desirable and in which it is not.
+
 ## Future enhancements
 
 We strive to keep the design simple and uncluttered, so at this point we put aside functionality, which is rarely used or would complicate language too much.