Add draft "Rosetta stone" by @fricklerhandwerk and stub commentary

The idea and most of the execution are @fricklerhandwerk's. I changed a
few things best I could based on @edolstra's corrections, and a Bazel
glossary.

Valentin Gagarin <valentin@fricklerhandwerk.de>

doc/manual/src/SUMMARY.md.in

@@ -26,7 +26,8 @@
       - [Input-Addressing](design/store/drvs/ia.md)
       - [Content-Addressing (Experimental)](design/store/drvs/ca.md)
     - [Building](design/store/building.md)
-    - [Advanced Topic: store object relocatability](design/store/relocatability.md)
+    - [Advanced Topic: Store object relocatability](design/store/relocatability.md)
+    - [Advanced Topic: Related work](design/store/related-work.md)
 - [Package Management](package-management/package-management.md)
   - [Basic Package Management](package-management/basic-package-mgmt.md)
   - [Profiles](package-management/profiles.md)

doc/manual/src/design/store/related-work.md

@@ -0,0 +1,37 @@
+# Advanced Topic: Related Work
+
+## Bazel
+
+TODO skylark and layering.
+
+TODO being monadic, if RFC 92.
+
+## Build Systems à la Carte
+
+TODO user-choosen keys vs keys chosen automatically?
+Purity in face of dynamic tasks (no conflicts, guaranteed).
+
+TODO Does Nix constitute a different way to be be monadic?
+Purity of keys, as mentioned.
+Dynamic tasks/keys vs dynamic dependencies.
+(Not sure yet.)
+
+## Lazy evaluation
+
+We clearly have thunks that produce thunks, but less clearly functions that produce functions.
+
+Do we have open terms?
+
+Do we hve thunks vs expressions distinction?
+c.f. John Shutt's modern fexprs, when the syntax can "leak".
+
+## Machine models
+
+TODO
+Derivations as store objects via drv files makes Nix a "Von Neumann" archicture.
+Can also imagine a "Harvard" archicture where derivations are stored separately?
+Can we in general imagine N heaps for N different sorts of objects?
+
+TODO
+Also, leaning on the notion of "builtin builders" more, having multiple different sorts of user-defined builders too.
+The builder is a black box as far as the Nix model is concerned.

doc/manual/src/design/store/store.md

@@ -1,5 +1,27 @@
+# Nix Store
+
 A Nix store is a collection of *store objects* referred to by *store paths*.
 Every store also has a "store directory path", which is a path prefix used for various purposes.
 
 There are many types of stores, but all of them at least respect this model.
 Some however offer additional functionality.
+
+## A Rosetta stone for the Nix store.
+
+The design of Nix is comparable to other build systems, even programming languages in general.
+Here is a rough [Rosetta stone](https://en.m.wikipedia.org/wiki/Rosetta_Stone) for build system terminology.
+If you are familiar with one of these columns, this might help the following sections make more sense.
+
+generic build system | Nix | Bazel | Build Systems à la Carte | lazy programming language
+-- | -- | -- | -- | --
+data (build input, build result) | component | file (source, target) | value | value
+build plan | derivation graph | action graph | `Tasks` | thunk
+build step | derivation | rule | `Task` | thunk
+build instructions | builder | (depends on action type) | `Task` | function
+build | build | build | `Build` applied to arguments | evaluation
+persistence layer | store | file system | `Store` | heap
+
+(n.b. Bazel terms gotten from https://docs.bazel.build/versions/main/glossary.html.)
+
+Plenty more could be said elaborating these comparisons.
+We will save that for the end of this chapter, in the [Related Work](./related-work.md) section.