Challenge 3: What Rust's Borrow Checker Rejects That C++ Allows — Possible Solution
====================================================================

Concrete scenario: imagine a shared integer, and code that takes a
mutable reference to it, then ALSO takes a second, ordinary (shared)
reference to that same integer, and uses both references while both
are still "alive" -- e.g., using the mutable reference to modify the
value in one line, and the second reference to read it in the very
next line, with no synchronization of any kind between the two uses.

In C++, per the chapter, this compiles and runs with no complaint at
all -- a T& and a second T& (or const T&) to the same object are
allowed to coexist freely, and nothing in the language checks or
restricts how they're used relative to each other. If the two
references happened to be used from two different threads
simultaneously (directly connecting to cpp3-4's own concurrency
chapter), this is exactly the shape of an unsynchronized data race --
compiles fine, runs, and produces genuinely undefined/unpredictable
results.

Rust's borrow checker would REJECT the equivalent code outright, at
COMPILE TIME, before it ever runs: Rust's rule is that a piece of data
can have either exactly one mutable reference OR any number of shared
references alive at once -- never both a mutable reference and any
other reference (mutable or shared) coexisting. The moment code
attempts to create that second reference while the mutable one is
still in scope and usable, the compiler refuses to build the program,
citing a borrow-checking error.

Why this specific gap is described as "ergonomics, not safety": C++
references genuinely DO fix the raw-pointer ergonomics problems this
whole course has covered -- no null state, no accidental rebinding, no
explicit dereference syntax cluttering the code. Those are real,
significant usability improvements over C's raw pointers. But NONE of
that addresses the deeper SAFETY question of whether two references to
the same data can be used in a way that corrupts it -- C++ references
offer zero enforcement on that question, exactly the same "zero
enforcement" verdict this course has reached for pointers, unions,
memory management, and concurrency throughout the entire C and C++
tracks. Rust's borrow checker is what actually closes that specific
gap, at compile time, which C++'s references -- despite looking
superficially similar to Rust's -- simply do not.

WHY THIS WORKS AS AN ANSWER
------------------------------
This constructs a concrete scenario (a mutable reference plus a second
reference to the same data, used without synchronization) rather than
an abstract description, states Rust's actual rule precisely (one
mutable XOR many shared, never both), and explains the
ergonomics-vs-safety distinction by naming specifically what C++
references DO fix (null, rebinding, dereference syntax) versus what
they explicitly don't (aliasing/mutation safety).