Add some more documentation

README.md

@@ -119,3 +119,74 @@ does not come naturally to Nix (since it builds each package fully
 independently).
 
 I think I will be able to fix this but I haven't implemented it yet.
+
+## Frequently Anticipated Questions
+
+### What's wrong with `straight.el`?
+
+`straight.el` is great, but its features are somewhat at odds with Nix:
+
+- `straight.el` can fetch package build recipes and packages. We cannot use this
+  from within Nix's build sandbox: we would need to build a system similar to
+  how emacs-overlay updates elpa / melpa and get `straight.el` to use it.
+- `straight.el` maintains a tree of mutable Git checkouts: you can edit these
+  directly or use `straight.el` to maintain them. The Nix store is immutable so
+  none of this will work.
+- `straight.el` can build packages, but so can nixpkgs / emacs-overlay.
+
+Doom heavily uses `straight.el` during `doom sync`, but it does not use it at
+all at startup and barely uses it after that. Since we're replacing `doom sync`
+in its entirety, bypassing `straight.el` seems simpler than trying to use it
+just for package builds.
+
+### Unstraightened seems to use `package.el`. Isn't that bad?
+
+Doom's FAQ offers [several arguments against
+`package.el`](https://github.com/doomemacs/doomemacs/blob/master/docs/faq.org#why-does-doom-use-straightel-and-not-packageel).
+They boil down to two problems, neither of which applies to Unstraightened:
+
+- `package.el` always builds from head: no rollback, no pinning, no
+  reproducibility, no way to override the package source used. Unstraightened
+  does not use `package.el` to fetch packages: it leaves that to Nix. We can
+  handle pinning there, and Nix flakes add further reproducibility and rollback
+  beyond what Doom's pins offer.
+- `package.el` can be slow to initialize. Doom normally speeds up startup by
+  combining autoloads from all installed packages into one file. Because
+  `package.el` produces autoload files much like `straight.el` does, and we're
+  loading everything from the immutable Nix store, we can apply exactly the same
+  approach to `package.el`. Unstraightened startup performance should be about
+  the same as vanilla Doom.
+
+### It's so slow to build!
+
+Parallel builds should help (set Nix's `max-jobs` to something greater than 1),
+but it is a bit slow.
+
+There are a few issues:
+
+- Unstraightened uses
+  [IFD](https://nixos.org/manual/nix/stable/language/import-from-derivation) to
+  determine packages to install and to determine package dependencies for
+  packages not in emacs-overlay. Especially the latter is slow.
+
+  - The dependency data probably gets garbage-collected, making subsequent
+    evaluation slow even if nothing changed. I intend to make the installed
+    packages depend on this data to work around this, but I have not implemented
+    it yet.
+
+- Doom (currently) [does not native-compile ahead of
+  time](https://github.com/doomemacs/doomemacs/issues/6811), but Unstraightened
+  (or nixpkgs, really), does.
+
+  - It should be possible to disable nativecomp and/or move it to runtime, but
+    see the next point...
+
+- Unstraightened's packages should be cacheable, but I don't have that set up
+  yet.
+
+  - In particular, Unstraightened's generated derivations for elisp packages do
+    not depend on the exact Doom source or configuration they're generated from.
+    They depend on the pinned version and Emacs binary used to build them, but
+    not much else. So it should be possible to build a Doom configuration with
+    just a few modules enabled using commonly-used versions of Emacs from CI and
+    push the results to a binary cache like https://cachix.org/.