YouTrack links to the new issues

notes/value-classes.md

@@ -603,6 +603,8 @@ Likewise, there is no immediate benefit in requiring extra call-side syntax for
 It would be great if we can figure out a way to distinguish (and, at least, underline in an IDE) mutating methods of regular, mutable classes. However, unlike value classes, where non-mutating methods and mutating methods are clearly distinct (by the virtue of the `mutating` modifier), there is no such clear distinction in the world of mutable classes. Developers can only rely on naming conventions and deep knowledge of libraries they use to avoid various mutation-related pitfalls.
 
 > We’d also like to explore potential approaches to explicitly marking mutating methods of mutable classes in the future, so they are distinct from read-only methods of mutable classes. It is a simple concept, that C++, for example, supports in the form of `const` methods. However, from a standpoint of modern software development practices, it is quite clear that C++ had chosen the wrong default. The default should be for the absence of mutation, while the ability to mutate an object should be explicit. Anyway, this thought avenue is out of the scope of this document that is focused on immutable value classes.
+> 
+> Corresponding umbrella issue is [KT-46067](https://youtrack.jetbrains.com/issue/KT-46067).
 
 ### Value interfaces
 
@@ -648,6 +650,8 @@ This potential 3rd-party mutation of a read-only `List` is usually not a concern
 We cannot reuse the read-only `List` type from the Kotlin standard library in the meaning of an immutable list, we cannot declare `List` as a value interface, since `List` interface can be and is implemented by mutable, non-value classes. We’ll have to introduce a separate set of interfaces, like `value interface ImmutableList<T>`, to be implemented by immutable value classes for the purpose of their use in immutable data structures. This explosion of collection interfaces (`List`, `MutableList`, `ImmutableList`) with a lot of duplication in the utility functions that are available for those interfaces, can be addressed by introducing a separate language feature to perform mutability-projection of types. The `MutableList` interface can become a _mutable projection_ of a `List` interface, written as `mutable List` (here `mutable` becomes a modifier for a type, not a part of its name anymore), while `ImmutableList` can likewise become an _immutable projection_ of a `List` interface, written as `immutable List`. All the methods and functions declared on a `List` will be marked with appropriate modifiers, allowing compiler to figure out which mutability type projection gives access to which functions. However, further elaboration of this potential scheme is outside the scope of this document, since these kinds of tagged projections are useful outside the world of mutability/immutability and should be undertaken in separate design effort.
 
 > It is also worth noting, that there is a lot of existing research into this kind of type-lattices with mutable, read-only, and immutable types, including a number of research and experimental languages supporting them. Some of those systems provide means that allow creation of mutable instances in the limited scope of construction and, somehow ensuring those instance did not escape the construction code via a mutable type, upgrade those instances to an immutable type without having to copy them. We might be able to adapt some of that research for Kotlin, too, further narrowing the gap between mutable and immutable data types, but that’s a separate topic. Here we focus on enhancing the story of immutable value types in Kotlin.
+> 
+> The umbrella issue, that covers scope restriction analysis, is [KT-46066](https://youtrack.jetbrains.com/issue/KT-46066).
 
 ### Mutating functions returning a value