(#8831) [docs] Why are version rangers not allowed?

* Why are version rangers not allowed

* fix up some typos I noticed while scrolling

* Apply suggestions from code review

Co-authored-by: Uilian Ries <uilianries@gmail.com>

* Apply suggestions from code review

Co-authored-by: Uilian Ries <uilianries@gmail.com>

Co-authored-by: Uilian Ries <uilianries@gmail.com>

docs/faqs.md

@@ -30,6 +30,7 @@ This section gathers the most common questions from the community related to pac
   * [What is the policy for supported python versions?](#what-is-the-policy-for-supported-python-versions)
   * [How to package libraries that depend on proprietary closed-source libraries?](#how-to-package-libraries-that-depend-on-proprietary-closed-source-libraries)
   * [How to _protect_ my project from breaking changes in recipes?](#how-to-_protect_-my-project-from-breaking-changes-in-recipes)<!-- endToc -->
+  * [Why are version ranges not allowed?](#why-are-version-ranges-not-allowed)<!-- endToc -->
 
 ## What is the policy on recipe name collisions?
 
@@ -138,7 +139,9 @@ There are some recipes in `conan-center-index` that provide packages that contai
 
 We decided that these packages (as long as they match the premises) should list all the settings needed to build, so building from sources will generate the expected binary, but they will **remove `compiler` setting inside the `package_id()` method**. As a consequence, the CI will generate packages only for one compiler reducing the workload in the pipeline and the number of possible package IDs.
 
-Note about `build_type`.- We retain the `build_type` setting to make it possible for the users to _debug_ these installer packages. We considered removing this settings and it would be possible to compile these packages in _debug_ mode, but if we remove it from the packageID, the compiled package would override the existing _release_ binary, and it'd be quite inconvenient for the users to compile the binary every time they need to switch from _debug_ to _release_.
+Notes about `build_type`:
+
+We retain the `build_type` setting to make it possible for the users to _debug_ these installer packages. We considered removing this settings and it would be possible to compile these packages in _debug_ mode, but if we remove it from the packageID, the compiled package would override the existing _release_ binary, and it'd be quite inconvenient for the users to compile the binary every time they need to switch from _debug_ to _release_.
 
 ## Can I remove an option from recipe
 
@@ -187,7 +190,7 @@ def configure(self):
     tools.check_min_cppstd(self, 14) 👈 Wrong!
 ```
 
-This fails to cover the waste number of use cases for the following reasons:
+This fails to cover the vast number of use cases for the following reasons:
 
 1. `cppstd` is not configured in the `--detect`ed profiles generated by Conan, the majority of users simply do not have this setting.
 2. A shocking number of projects override this setting within their respective build scripts, this setting does not get applied in those cases.
@@ -334,3 +337,9 @@ To isolate from this changes there are different strategies you can follow:
    and lockfiles. 
 
 Keep reading in the [consuming recipes section](consuming_recipes.md).
+
+## Why are version ranges not allowed?
+
+Version ranges are a useful Conan feature, find the documentation [here](https://docs.conan.io/en/latest/versioning/version_ranges.html). However, in the context of ConanCenter they pose a few key challenges, most notably "Build Reproducibility".
+
+If consumers try to download and build the recipe at a later time, it may resolve to a different package version that may not be compatible. In order to prevent these types of issues, we have decided to only allow exact requirements versions.