Apply suggestions from code review

Co-authored-by: Robert Hensing <roberth@users.noreply.github.com>

doc/manual/src/store/store-object/content-address.md

@@ -1,7 +1,8 @@
 # Content-Addressing Store Objects
 
 Just [like][fso-ca] [File System Objects][File System Object],
-[Store Objects][Store Object] can also be [content addressed](@docroot@/glossary.md#gloss-content-addressed).
+[Store Objects][Store Object] can also be [content-addressed](@docroot@/glossary.md#gloss-content-addressed),
+unless they are [input-addressed](@docroot@/glossary#gloss-input-addressed-store-object).
 
 For store objects, the content address we produce will take the form of a [Store Path] rather than regular hash.
 In particular, the content-addressing scheme will ensure that the digest of the store path is solely computed from the
@@ -23,8 +24,7 @@ For the full specification of the algorithms involved, see the [specification of
 
 ### File System Objects
 
-With all currently supported store object content addressing methods, the file system object is always content-addressed first, and then that hash incorporated in further calculations.
-As such, the conte-addressing of the file system objects part of a store object is exactly as described in the [section on content-addressing file system objects][fso-ca].
+With all currently supported store object content addressing methods, the file system object is always [content-addressed][fso-ca] first, and then that hash is incorporated into content address computation for the store object.
 
 ### References
 
@@ -37,9 +37,10 @@ Self-references however cannot be referred to by their path, because we are in t
 > ```
 > digest = hash(..... || digest || ....)
 > ```
-> which is computationally infeasible, being no easier than finding a hash collision.
+> which is computationally infeasible.
+> As far as we know, this is equivalent to finding a hash collision.
 
-Instead we just have a "has self reference" boolean, which will end up effecting the digest.
+Instead we just have a "has self reference" boolean, which will end up affecting the digest.
 
 ### Name and Store Directory
 
@@ -56,24 +57,24 @@ The names and store directories are unrestricted however.
 
 This uses the corresponding [Flat](../file-system-object/content-address.md#serial-flat) method of file system object content addressing.
 
-References are not supported.
+References are not supported: store objects with flat hashing *and* references can not be created.
 
 ### Text { #method-text }
 
 This also uses the corresponding [Flat](../file-system-object/content-address.md#serial-flat) method of file system object content addressing.
 
-References to other store objects are supported, but not self reference are not.
+References to other store objects are supported, but self references are not.
 
 This is the only store-object content-addressing method that is not named identically with a corresponding file system object method.
 It is somewhat obscure, mainly used for "drv files"
 (derivations serialized as store objects in their ["ATerm" file format](@docroot@/protocols/derivation-aterm.md)).
-Prefer using another method if possible.
+Prefer another method if possible.
 
 ### Nix Archive { #method-nix-archive }
 
 This uses the corresponding [Nix Archive](../file-system-object/content-address.md#serial-nix-archive) method of file system object content addressing.
 
-References (to other store objects and self references alike) are supported so long as the hash algorithm in use is [SHA-256], but not (neither kind) otherwise.
+References (to other store objects and self references alike) are supported so long as the hash algorithm is [SHA-256], but not (neither kind) otherwise.
 
 [SHA-256]: https://en.m.wikipedia.org/wiki/SHA-256
 
@@ -94,7 +95,8 @@ If SHA-256-based Git becomes more widespread, this restriction would be revisite
 
 ### Reproducibility
 
-The above system is rather more complex than it needs to be, owning to accretion of features over time.
+The above system is more complex than it needs to be to support all types of file system objects and references, owing to accretion of features over time.
+However, there's a lot of value in supporting old expressions and reproducing the same hashes with any version of Nix.
 Still, the fundamental property remains that if one knows how a store object is supposed to be hashed
 --- all the non-Hash, non-references information above
 --- one can recompute a store object's store path just from that metadata and its content proper (its references and file system objects).