Wording improvements

docs/support-for-generic-function-types-in-user-defined-type-functions.md

@@ -2,25 +2,27 @@
 
 ## Summary
 
-Add support for generic function types in user-defined type functions to allow more types to be accepted by them, including tables and classes which might contain generic function types.
+Add support for generic function types in type functions to allow more types to be accepted by them, including tables and classes which might contain generic function types.
 
 ## Motivation
 
-Generic functions are very common in Luau, especially when inferred by the typechecking engine. They are also often present in classes.
+Generic functions are very common in Luau, especially when inferred by the typechecking engine. They are also often present in classes defined by the environment.
 
-Omitting generic types from appearing in user-defined type functions limits their use.
-Even if there is no direct manipulation of generics, a serialization error appears immediately.
+Omitting generic types from appearing in type functions limits their use.
+Today, even if there is no direct manipulation of generics, a serialization error appears immediately.
+Ideally, we want use-defined type functions to support any possible type, aside from temporary implementation-detail types of the type solver.
 
 ## Design
 
-We will introduce a single 'generic' kind for both generic types and generic packs in runtime.
+We will introduce a single 'generic' kind of runtime type for both generic types and generic packs.
 
-While this doesn't match up the typechecking engine representation directly, we avoid having to deal with two different userdata types. Being opaque about the contents, assigning separate tags is also not that different.
+While this doesn't match up the typechecking engine representation directly, we avoid having to deal with two different userdata types.
+Being content of a generic type or pack is not known upfront, assigning separate tags is not that different from having an extra property on it.
 
-We already have variadic types that get represented as a regular runtime type in the 'tail' table member/arguments.
-We also have a different representation of a table with a metatable.
+We already have variadic types (`...number`) that get represented as a regular runtime type and only gain that special meaning when placed in a 'tail' spot.
+We also have a different representation of a table with a metatable between type functions and typechecking.
 
-Generics are created by specifying a name and whether or not it is a pack.
+Generics are created by specifying a name and a boolean marking it as a type or a pack.
 Generics that are coming from type inference might not have a display name, but still hold an auto-generated name internally.
 
 Names are the way generic identity is specified.
@@ -30,11 +32,11 @@ For example, consider a type `<T, U>(T, U, <T>(T) -> U) -> ()`
 
 From the typechecking perspective, inner and outer function 'T' types are different, but they are still represented by the same runtime generic named 'T'.
 
-The ambiguity is resolved purely on the scoping of the generic in question.
+The ambiguity is resolved based on the scoping of the generic in question.
 When the runtime type is returned back to the typechecking engine, only those generics that are in the current set of function type generic lists are allowed to be mentioned.
-When the inner generic function list places the name 'T' again, it represents a different typechecking type and hides the outer 'T'.
+When the inner generic function list places the name 'T' again, it represents a different typechecking type and hides the outer 'T' until the scope of the inner type ends.
 
-So we can say generics are defined by the lexical scope and that actually matches how they are written out in code.
+So we can say generics are defined by the lexical scope, which matches how they are written out in source code.
 
 Just like in the syntax of the language, reusing the same generic name, even between types and packs in a single list results in a duplicate generic definition error.
 
@@ -108,11 +110,11 @@ end
 We can assign a different `tag` to a generic pack instead of the `ispack` property.
 
 It is also possible to split a single list containing both generic types and packs into two.
-This was done in an initial prototype implementation as was inconvenient to specify.
-One benefit was that you didn't have to split them manually when reading them.
+This was done in an initial prototype implementation and was inconvenient to specify.
+One benefit was that list didn't have to be split manually when reading types or packs individually.
 
 ## Drawbacks
 
-Generics do bring additional complexity to user-defined type functions, especially with the way we can now hold a generic type pack as a separate item (while `type T = U...` impossible to define in the syntax of the language).
+Generics do bring additional complexity to type functions, especially with the way we can now hold a generic type pack as a separate item (while `type T = U...` impossible to define in the syntax of the language).
 
-The way they bring in lexical scoping consideration is also new for user-defined type functions.
+The way they bring in lexical scoping consideration is also new for type function runtime.