Mention that global state solutions usually use extra objects to mana…

…ge state

docs/src/content/docs/index.mdx

@@ -22,6 +22,7 @@ The pros of Disco are:
   - There is no need to create wrapper types or rely on IDs such as strings.
 - The API is very simple and feels natural to Flutter.
   - Providers are equipped with `of(context)` and `maybeOf(context)` methods.
+  - All you need is `BuildContext`. There is no additional object needed to manage the state.
 - The removal of a provider has an impact on its providing and each of its injections.
   - Each of them is immediately characterized by a static error.
 - The values held by the providers are immutable.

docs/src/content/docs/miscellaneous/comparison-with-alternatives.md

@@ -22,11 +22,13 @@ Due to the limitations mentioned earlier, the Flutter ecosystem saw the emergenc
 
 However, they introduce new challenges:
 
-- Be able to access everything from everywhere, which can lead to spaghetti code.
-- **Circular dependencies**  
+- **Unrestricted access**
+  - Being able to access everything from everywhere can lead to spaghetti code.
+- **Circular dependencies**
 - **Local-state-like logic** that doesn't behave exactly like real local state
-  - This complicates logic, especially for beginners.
-  - Sometimes it feels like you're fighting against the framework.
+  - This complicates the logic, especially for beginners.
+  - Some solution require objects of special classes to manage the global state.
+    - Passing these objects around (instead of passing `BuildContext` instances around) creates inconsistencies and can feel like working against the framework.
 - **Code generation** in some packages  
   - It should not be necessary.
   - Creates a high learning curve for new developers.