Apply suggestions from code review

Co-authored-by: Dmitri Gribenko <[email protected]>

Author: tall-vase

src/idiomatic/leveraging-the-type-system/borrow-checker-invariants.md

@@ -4,9 +4,8 @@ minutes: 10
 
 # Using the Borrow checker to enforce Invariants
 
-The logic of the borrow checker, while tied to "memory ownership", can be
-abstracted away from this central use case to model other problems and prevent
-API misuse.
+The borrow checker, while added to enforce memory ownership, can be
+leveraged model other problems and prevent API misuse.
 
 ```rust,editable
 // Doors can be open or closed, and you need the right key to lock or unlock
@@ -66,9 +65,7 @@ fn main() {
   wrong key the door is still closed (here represented as an error) and the key
   persists regardless.
 
-- The rules of the borrow checker exist to prevent developers from accessing,
-  changing, and holding onto data in memory in unpredictable ways without being
-  so restrictive that it would prevent _writing software_. The underlying
+- The rules of the borrow checker exist to prevent memory safety bugs. However, the underlying
   logical system does not "know" what memory is. All it does is enforce a
   specific set of rules of how different operations affect what later operations
   are possible.

src/idiomatic/leveraging-the-type-system/borrow-checker-invariants/single-use-values.md

@@ -32,7 +32,7 @@ fn main() {
 
 <details>
 
-- What if we want to be able to guarantee that a value can only be used once?
+- Problem: How can we guarantee a value is used only once?
 
 - Motivation: A nonce is a piece of random, unique data used in cryptographic
   protocols to prevent replay attacks.
@@ -46,8 +46,7 @@ fn main() {
 - Rust has an obvious tool for "Once you use this, you can't use it anymore":
   Using a value as an _owned argument_.
 
-- Highlight: the `encrypt` function takes references for `key` and `data` but
-  not `nonce`
+- Highlight: the `encrypt` function takes `nonce` by value (an owned argument), but `key` and `data` by reference.
 
 - By keeping constructors private and not implementing clone/copy for a type,
   making the interior type opaque (as per the newtype pattern), we can prevent