(RSRP-499137) Docs: update the notes on --omit-non-api-members

README.md

@@ -16,7 +16,7 @@ You could download refasmer from GitHub: https://github.com/JetBrains/Refasmer/r
 
 ## Usage:
 ```
-Usage: refasmer [options] <dll> [<**/*.dll> ...]
+refasmer [options] <dll> [<**/*.dll> ...]
 Options:
   -v                         increase verbosity
   -q, --quiet                be quiet
@@ -47,7 +47,7 @@ Mock assembly throws `System.NotImplementedException` in each imported method.
 Reference assembly contains only type definition and method signatures with no method bodies.
 
 > [!IMPORTANT]
-> Note that `--omit-non-api-types` performs a nontrivial transformation on the resulting assembly. Normally, a reference assembly should include any types participating as private members of any value type, because this is up to the spec. However, in some cases, it is possible to omit these types from the reference assembly, because they are not part of the public API, while preserving some of the value type semantics. In these cases, Refasmer is able to remove these types from the assembly, sometimes emitting synthetic fields in the output type. This will preserve the difference of empty and non-empty struct types, but will not preserve the type blittability (i.e. some types after refasming might obtain the ability to follow the `: unmanaged` constraint, even if they were unable before refasming).
+> Note that `--omit-non-api-members` performs a nontrivial transformation on the resulting assembly. Normally, a reference assembly should include any types, including private and internal ones, because this is up to the spec. However, in some cases, it is possible to omit private and internal types from the reference assembly, because they are not part of the public API, while preserving some of the value type semantics. In these cases, Refasmer is able to remove these types from the assembly, sometimes emitting synthetic fields in the output type. This will preserve the difference of empty and non-empty struct types, but will not preserve the type blittability (i.e. some types after refasming might obtain the ability to follow the `unmanaged` constraint, even if this wasn't possible before refasming).
 
 ## Examples: