docs: 2.2 release announcement updated

docs/blog/posts/2.2.0-released.md

@@ -31,12 +31,12 @@ the C++ modules' support is still really limited.
 
     To benefit from C++ modules, we need at least:
 
-    - CMake 3.28.1
+    - CMake 3.29.3
     - Ninja 1.11
     - clang-17
 
-In the upcoming months, hopefully, the situation will improve with the gcc-14 release and
-bug fixes in MSVC.
+In the upcoming months, hopefully, the situation will improve with the bug fixes in
+CMake, gcc-14, and MSVC.
 
 !!! note
 
@@ -64,6 +64,11 @@ flowchart TD
 The easiest way to use them is just to `import mp_units;` at the beginning of your translation unit
 (see the [Quick Start](../../getting_started/quick_start.md) chapter for some usage examples).
 
+!!! note
+
+    C++20 modules support still have some issues when imported from the installed CMake target.
+    See the following [GitLab issue for more details](https://gitlab.kitware.com/cmake/cmake/-/issues/25909#note_1525377).
+
 In this release, we also highly limited the number of CMake targets (:boom: **breaking change** :boom:).
 Now, they correspond exactly to the C++ modules they provide. This means that many smaller partial
 targets were removed. We also merged text output targets with the core library's definition.
@@ -93,9 +98,9 @@ In version 2.2, the following headers have a new location or contents:
 Benefiting from this opportunity, we also cleaned up core and systems definitions
 (:boom: **breaking change** :boom:).
 
-Regarding the library's core, we exposed only one header `framework.h` that exposes all of
-the library's framework so the user does not have to enumerate files like `unit.h`, `quantity.h`,
-and `quantity_point.h` anymore. Those headers are not gone, they were put to
+Regarding the library's core, we removed `core.h` and exposed only one header `framework.h` that
+provides all of the library's framework so the user does not have to enumerate files like `unit.h`,
+`quantity.h`, and `quantity_point.h` anymore. Those headers are not gone, they were put to
 the `mp-units/framework` subheader. So they are still there if you really need them.
 
 Regarding the changes in systems definitions, we moved the wrapper header files with the entire
@@ -153,6 +158,11 @@ three values:
 - `False` - The feature is disabled, and an older alternative is always used.
 - `Auto` - The feature is automatically enabled if the compiler supports it (old behavior).
 
+Before this release, the library always depended on [gsl-lite](https://github.com/gsl-lite/gsl-lite)
+to perform runtime contract and asserts checking. In this release we introduced new options
+to control if contract checking should be based on [gsl-lite](https://github.com/gsl-lite/gsl-lite),
+[ms-gsl](https://github.com/microsoft/GSL), or maybe completely disabled.
+
 Additionally, some CMake options were renamed to better express the impact on our users
 (:boom: **breaking change** :boom:). For example, now CMake options include:
 
@@ -191,7 +201,7 @@ origins. For example:
     ```
 
 As we can see above, the new design allows
-[direct-initialization](https://en.cppreference.com/w/cpp/language/direct_initialization) of a
+[direct-initializing](https://en.cppreference.com/w/cpp/language/direct_initialization)
 `quantity_point` class template from a `quantity`, but only if the former one is defined in terms
 of the implicit point origin. Otherwise, an explicit origin still always has to be provided during
 initialization.
@@ -199,7 +209,7 @@ initialization.
 Also, we introduced the possibility of specifying a default point origin in the unit definition.
 With that, we could provide proper temperature scales without forcing the user to always use
 the origins explicitly. Also, a new member function, `.quantity_from_zero(),` was introduced
-that always returns the quantity from the unit's specific point origin or from the absolute
+that always returns the quantity from the unit's specific point origin or from the implicit
 point origin otherwise.
 
 === "Now"
@@ -244,20 +254,30 @@ named with its corresponding unit and with the `si::zeroth_degree_Celsius`
 about potential ABI issues when different translation units are compiled with different ordinary
 literal encodings. Those issues were resolved with a change to units definitions
 (:boom: **breaking change** :boom:). It affects only units that specify both Unicode and ASCII
-symbols. The new design requires the Unicode symbol to be provided as a UTF-8 literal:
+symbols. The new design requires the Unicode symbol to be provided as a UTF-8 literal.
+
+This also means that the `basic_symbol_text` has fixed character types for both symbols. This
+is why it was renamed to `symbol_text` (:boom: **breaking change** :boom:).
 
 === "Now"
 
     ```cpp
-    inline constexpr struct ohm : named_unit<{u8"Ω", "ohm"}, volt / ampere> {} ohm;
+    inline constexpr struct ohm : named_unit<symbol_text{u8"Ω", "ohm"}, volt / ampere> {} ohm;
     ```
 
 === "Before"
 
     ```cpp
-    inline constexpr struct ohm : named_unit<{"Ω", "ohm"}, volt / ampere> {} ohm;
+    inline constexpr struct ohm : named_unit<basic_symbol_text{"Ω", "ohm"}, volt / ampere> {} ohm;
     ```
 
+!!! note
+
+    On C++20-compliant compilers it should be enough to type the following in the unit's definition:
+
+    ```cpp
+    inline constexpr struct ohm : named_unit<{u8"Ω", "ohm"}, volt / ampere> {} ohm;
+    ```
 
 ## Improved text output