We have all used Box<T> before in our Rust code. It’s a glorious type, with great ergonomics and flexibility. We can use it to put our values on the heap, but it can do even more than that!

struct Fields {
@@ -114,7 +114,9 @@ provide an aliasable version of Box<T>, which is used by the sel
 So if box stayed unique, people could also just pick up that crate as a dependency and use the aliasable box from there instead of
 having to write their own. Interestingly, this crate also provides a Vec<T>, even though Vec<T> can currently be aliased in practice and
 in the current version of stacked borrows. just fine, although it’s also not clear whether we want to keep it like this, but I
-don’t think this can reasonable be changed.
noalias, noslow⌗
There is one clear potential benefit from this box behaviour: ✨Optimizations✨. noalias doesn’t exist for fun, it’s something
+don’t think this can reasonable be changed.
One thing was just pointed out to me after releasing the post: Mutation usually goes through &mut T anyways, even when the value
+is stored as a Box<T>. Therefore, all the guarantees of uniqueness are already present when mutating boxes, making the uniqueness
+of box even less important.
noalias, noslow⌗
There is one clear potential benefit from this box behaviour: ✨Optimizations✨. noalias doesn’t exist for fun, it’s something
 that can bring clear performance wins (for noalias on &mut T, those were measureable). So the only question remains:
 How much performance does noalias on Box<T> give us now, and how many potential performance improvements could we get in the
 future? For the latter, there is no simple answer. For the former, there is. rustc has no performance improvements
diff --git a/posts/index.xml b/posts/index.xml
index c186ec9..8f42c2d 100644
--- a/posts/index.xml
+++ b/posts/index.xml
@@ -148,6 +148,11 @@ So if box stayed unique, people could also just pick up that crate as a dependen
 having to write their own. Interestingly, this crate also provides a <code>Vec&lt;T&gt;</code>, even though <code>Vec&lt;T&gt;</code> can currently be aliased in practice and
 in the current version of stacked borrows. just fine, although it&rsquo;s also not clear whether we want to keep it like this, but I
 don&rsquo;t think this can reasonable be changed.</p>
+<blockquote>
+<p>One thing was just pointed out to me after releasing the post: Mutation usually goes through <code>&amp;mut T</code> anyways, even when the value
+is stored as a <code>Box&lt;T&gt;</code>. Therefore, all the guarantees of uniqueness are already present when mutating boxes, making the uniqueness
+of box even less important.</p>
+</blockquote>
 <h1 id="noalias-noslow">noalias, noslow</h1>
 <p>There is one clear potential benefit from this box behaviour: ✨Optimizations✨. <code>noalias</code> doesn&rsquo;t exist for fun, it&rsquo;s something
 that can bring clear performance wins (for <code>noalias</code> on <code>&amp;mut T</code>, those were measureable). So the only question remains:
diff --git a/tags/rust/index.xml b/tags/rust/index.xml
index 1fe4f31..fc7bde5 100644
--- a/tags/rust/index.xml
+++ b/tags/rust/index.xml
@@ -148,6 +148,11 @@ So if box stayed unique, people could also just pick up that crate as a dependen
 having to write their own. Interestingly, this crate also provides a <code>Vec&lt;T&gt;</code>, even though <code>Vec&lt;T&gt;</code> can currently be aliased in practice and
 in the current version of stacked borrows. just fine, although it&rsquo;s also not clear whether we want to keep it like this, but I
 don&rsquo;t think this can reasonable be changed.</p>
+<blockquote>
+<p>One thing was just pointed out to me after releasing the post: Mutation usually goes through <code>&amp;mut T</code> anyways, even when the value
+is stored as a <code>Box&lt;T&gt;</code>. Therefore, all the guarantees of uniqueness are already present when mutating boxes, making the uniqueness
+of box even less important.</p>
+</blockquote>
 <h1 id="noalias-noslow">noalias, noslow</h1>
 <p>There is one clear potential benefit from this box behaviour: ✨Optimizations✨. <code>noalias</code> doesn&rsquo;t exist for fun, it&rsquo;s something
 that can bring clear performance wins (for <code>noalias</code> on <code>&amp;mut T</code>, those were measureable). So the only question remains:
diff --git a/tags/unsafe-code/index.xml b/tags/unsafe-code/index.xml
index 1a72d7f..3ba9d86 100644
--- a/tags/unsafe-code/index.xml
+++ b/tags/unsafe-code/index.xml
@@ -148,6 +148,11 @@ So if box stayed unique, people could also just pick up that crate as a dependen
 having to write their own. Interestingly, this crate also provides a <code>Vec&lt;T&gt;</code>, even though <code>Vec&lt;T&gt;</code> can currently be aliased in practice and
 in the current version of stacked borrows. just fine, although it&rsquo;s also not clear whether we want to keep it like this, but I
 don&rsquo;t think this can reasonable be changed.</p>
+<blockquote>
+<p>One thing was just pointed out to me after releasing the post: Mutation usually goes through <code>&amp;mut T</code> anyways, even when the value
+is stored as a <code>Box&lt;T&gt;</code>. Therefore, all the guarantees of uniqueness are already present when mutating boxes, making the uniqueness
+of box even less important.</p>
+</blockquote>
 <h1 id="noalias-noslow">noalias, noslow</h1>
 <p>There is one clear potential benefit from this box behaviour: ✨Optimizations✨. <code>noalias</code> doesn&rsquo;t exist for fun, it&rsquo;s something
 that can bring clear performance wins (for <code>noalias</code> on <code>&amp;mut T</code>, those were measureable). So the only question remains: