Update docs/extensibility/visualstudio.extensibility/extensibility-models.md

Co-authored-by: Gordon Hogenson <[email protected]>

Author: tinaschrepfer

docs/extensibility/visualstudio.extensibility/extensibility-models.md

@@ -190,7 +190,7 @@ You can of course switch back to a background thread after this call. However, a
 
 ### Simple API versus simple concepts
 
-Because Community Toolkit hides away many of the intricacies of VSSDK, it could give extenders a false sense of simplicity. Let's continue with the same sample code, if an extender didn't know about the threading requirements of Visual Studio development, they might assume that their code is run from a background thread the whole time. They'll take no issue with the fact that the call to read a file from text is synchronous. If it's on a background thread, it won't freeze the UI if the file in question is large. However, when the code is unwrapped to VSSDK, they'll realize that that's not the case. So, while the API from Community Toolkit certainly looks simpler to understand and more cohesive to write, because it's tied to VSSDK, it's subject to VSSDK limitations. The simplicities can gloss over important concepts that if extenders don't understand, it can cause more harm. VisualStudio.Extensibility avoids the many issues caused by main-thread dependencies by focusing on the out-of-process model and async APIs as our foundation. While running out of the process would simplify threading the most, many of these benefits carry over to extensions that are run in-process as well. For example, VisualStudio.Extensibility commands are always executed on a background thread. Interacting with VSSDK APIs still requires in-depth knowledge of how threading works, but at least you won't pay the cost of accidental hangs, as in this example.
+Because Community Toolkit hides away many of the intricacies of VSSDK, it could give extenders a false sense of simplicity. Let's continue with the same sample code. If an extender didn't know about the threading requirements of Visual Studio development, they might assume that their code is run from a background thread the whole time. They'll take no issue with the fact that the call to read a file from text is synchronous. If it's on a background thread, it won't freeze the UI if the file in question is large. However, when the code is unwrapped to VSSDK, they'll realize that's not the case. So, while the API from Community Toolkit certainly looks simpler to understand and more cohesive to write, because it's tied to VSSDK, it's subject to VSSDK limitations. The simplicities can gloss over important concepts that, if extenders don't understand, can cause more harm. VisualStudio.Extensibility avoids the many issues caused by main-thread dependencies by focusing on the out-of-process model and async APIs as our foundation. While running out of the process would simplify threading the most, many of these benefits carry over to extensions that are run in-process as well. For example, VisualStudio.Extensibility commands are always executed on a background thread. Interacting with VSSDK APIs still requires in-depth knowledge of how threading works, but at least you won't pay the cost of accidental hangs, as in this example.
 
 ## Comparison chart