README: expand the caveats section a bit

For #13, mainly, since that's a common concern.

README.md

@@ -40,17 +40,28 @@ binary doesn't include paths from the current filesystem.
 
 ### Caveats
 
+Most of these can improve with time and effort. The purpose of this section is
+to document the current shortcomings of this tool.
+
+* Package import path names are never garbled, since we require the original
+  paths for the build system to work. See #13 to investigate alternatives.
+
 * The `-a` flag for `go build` is required, since `-toolexec` doesn't work well
-  with the build cache; see [#27628](https://github.com/golang/go/issues/27628).
+  with the build cache; see [golang/go#27628](https://github.com/golang/go/issues/27628).
 
-* Since no caching at all can take place right now (see the link above), builds
-  will be slower than `go build` - especially for large projects.
+* Since no caching at all can take place right now (see the link above), fast
+  incremental builds aren't possible. Large projects might be slow to build.
 
 * The standard library is never garbled when compiled, since the source is
-  always publicly available.
+  always publicly available. See #7 for making this configurable.
 
 * Deciding what method names to garble is always going to be difficult, due to
-  interfaces that could be implemented up or down the package import tree.
+  interfaces that could be implemented up or down the package import tree. At
+  the moment, exported methods are never garbled.
 
 * Similarly to methods, exported struct fields are difficult to garble, as the
-  names might be relevant for reflection work like `encoding/json`
+  names might be relevant for reflection work like `encoding/json`. At the
+  moment, exported methods are never garbled.
+
+* Functions implemented outside Go, such as assembly, aren't garbled since we
+  currently only transform the input Go source.