diff --git a/docs/getting_started/faq.md b/docs/getting_started/faq.md
index 25e4cb6d..b08e2aec 100644
--- a/docs/getting_started/faq.md
+++ b/docs/getting_started/faq.md
@@ -25,6 +25,10 @@ Many reasons make UDLs a poor choice for a physical units library:
     static_assert(std::is_same_v<decltype(d2)::rep, long double>);
     ```
 
+   When such UDL is intermixed in arithmetics with any quantity type of a shorter representation
+   type, it will always expand it to the longest one. In other words, such long type spreads until
+   all types use it everywhere.
+
 3. While increasing the coverage for the library, we learned that many unit symbols conflict with
    built-in types or numeric extensions. A few of those are: `F` (farad), `J` (joule), `W` (watt),
    `K` (kelvin), `d` (day), `l` or `L` (litre), `erg`, `ergps`. Usage of the `_` prefix would make
diff --git a/docs/users_guide/framework_basics/interface_introduction.md b/docs/users_guide/framework_basics/interface_introduction.md
index 03364419..f1bcc16f 100644
--- a/docs/users_guide/framework_basics/interface_introduction.md
+++ b/docs/users_guide/framework_basics/interface_introduction.md
@@ -81,7 +81,7 @@ without having to introduce hundreds of types to predefine them.
 ## Value-based equations
 
 The **mp-units** library is based on C++20, significantly improving user experience. One of
-such improvements are value-based equations.
+such improvements is the usage of value-based equations.
 
 As we have learned above, the entities are being used as values in the code, and they compose.
 Moreover, derived entities can be defined in the library using such value-based equations.
diff --git a/docs/users_guide/use_cases/interoperability_with_other_libraries.md b/docs/users_guide/use_cases/interoperability_with_other_libraries.md
index 2df4a512..ee3bbf77 100644
--- a/docs/users_guide/use_cases/interoperability_with_other_libraries.md
+++ b/docs/users_guide/use_cases/interoperability_with_other_libraries.md
@@ -182,13 +182,10 @@ type trait:
 For example, for our `Timestamp` type, we could provide the following:
 
 ```cpp
-inline constexpr struct TimestampOrigin :
-    mp_units::absolute_point_origin<TimestampOrigin, mp_units::isq::time> {} TimestampOrigin;
-
 template<>
 struct mp_units::quantity_point_like_traits<Timestamp> {
   static constexpr auto reference = si::second;
-  static constexpr auto point_origin = TimestampOrigin;
+  static constexpr auto point_origin = default_point_origin(reference);
   using rep = decltype(Timestamp::seconds);
 
   static constexpr convert_implicitly<quantity<reference, rep>> to_quantity(Timestamp ts)
@@ -203,7 +200,7 @@ struct mp_units::quantity_point_like_traits<Timestamp> {
 };
 ```
 
-After that, we can check that the [`QuantityLike`](../framework_basics/concepts.md#QuantityLike)
+After that, we can check that the [`QuantityPointLike`](../framework_basics/concepts.md#QuantityPointLike)
 concept is satisfied:
 
 ```cpp
@@ -226,7 +223,7 @@ int main()
   // implicit conversion
   quantity_point qp = ts;
 
-  std::cout << qp.quantity_from(TimestampOrigin) << "\n";
+  std::cout << qp.quantity_from_zero() << "\n";
 
   // explicit conversion
   print(Timestamp(qp));
@@ -286,7 +283,7 @@ Here is an example of how interoperability described in this chapter can be used
 ```cpp
 using namespace std::chrono;
 
-std::chrono::sys_seconds ts_now = floor<seconds>(system_clock::now());
+sys_seconds ts_now = floor<seconds>(system_clock::now());
 
 quantity_point start_time = ts_now;
 quantity speed = 925. * km / h;
@@ -294,7 +291,7 @@ quantity distance = 8111. * km;
 quantity flight_time = distance / speed;
 quantity_point exp_end_time = start_time + flight_time;
 
-std::chrono::sys_seconds ts_end = value_cast<int>(exp_end_time.in(s));
+sys_seconds ts_end = value_cast<int>(exp_end_time.in(s));
 
 auto curr_time = zoned_time(current_zone(), ts_now);
 auto mst_time = zoned_time("America/Denver", ts_end);