diff --git a/hsrc_lib/Database/VCache/Path.hs b/hsrc_lib/Database/VCache/Path.hs
--- a/hsrc_lib/Database/VCache/Path.hs
+++ b/hsrc_lib/Database/VCache/Path.hs
@@ -11,28 +11,20 @@
 maxPathLen :: Int
 maxPathLen = 511  -- key size limit from LMDB 0.9.10
 
--- | VCache implements a simplified filesystem metaphor. Developers 
--- can assign a distinct prefix for all PVars created by the VCache,
--- thus modeling namespaces or subdirectories. Assuming the normal 
--- advice of opening the VCache only once in the main module, these
--- prefixes enable transparent, modular decomposition of a VCache 
--- application without risk of name collisions.
---
--- VCache is simplistic about this: a prefix is appended directly.
--- If developers use subdir "foo" followed by "bar", the result is 
--- the same as "foobar". Separators are left to local conventions.
--- Consider "foo/" and "bar/" to model filesystem subdirectories. 
---                 
--- Paths have a limited maximum size of ~500 bytes, including the
--- final PVar name. A runtime error may be generated for oversized
--- paths. In practice, this should not be an issue. 
+-- | VCache implements a simplified filesystem metaphor. By assigning
+-- a different prefix for root PVars loaded by different subprograms,
+-- developers can guard against namespace collisions. Each component
+-- may have its own persistent roots.
+-- 
+-- While I call it a subdirectory, it really is just a prefix. Using
+-- "foo" followed by "bar" is equivalent to using "foobar". Developers
+-- should include their own separators if they expect them, i.e. "foo\/"
+-- and "bar\/".
 --
--- Usage Note: Subdirectories allow developers to control risk of
--- namespace collisions between modules or plugins. But they are not
--- intended for domain data! Avoid dynamically creating directories
--- or named PVars based on runtime data. It's better to push most
--- domain logic and schema into the PVar layer, which is subject to
--- rich type safety, GC, potential versioning, and other benefits.
+-- Paths are limited to ~500 bytes. For normal use, this limit will not
+-- be a problem. If you're creating PVars based on runtime inputs, those
+-- should always be dynamic PVars. Root PVar names should never be much 
+-- larger than fully qualified function names.
 --
 vcacheSubdir :: ByteString -> VCache -> VCache
 vcacheSubdir p (VCache vs d) = 
diff --git a/hsrc_lib/Database/VCache/VGet.hs b/hsrc_lib/Database/VCache/VGet.hs
--- a/hsrc_lib/Database/VCache/VGet.hs
+++ b/hsrc_lib/Database/VCache/VGet.hs
@@ -5,6 +5,7 @@
 
     -- * Prim Readers
     , getVRef, getPVar
+    , getVSpace
     , getWord8
     , getWord16le, getWord16be
     , getWord32le, getWord32be
@@ -116,6 +117,11 @@
             return (VGetR pvar s')
         _ -> return (VGetE "getPVar")
 {-# INLINABLE getPVar #-}
+
+-- | Read the VSpace. This value is constant for a full VGet operation.
+getVSpace :: VGet VSpace 
+getVSpace = VGet $ \ s -> return (VGetR (vget_space s) s)
+{-# INLINE getVSpace #-}
 
 -- | Read words of size 16, 32, or 64 in little-endian or big-endian.
 getWord16le, getWord16be :: VGet Word16
diff --git a/hsrc_lib/Database/VCache/VTx.hs b/hsrc_lib/Database/VCache/VTx.hs
--- a/hsrc_lib/Database/VCache/VTx.hs
+++ b/hsrc_lib/Database/VCache/VTx.hs
@@ -38,8 +38,8 @@
     let wsync' = updateSync bSync mvWait (write_sync w) in
     let w' = Writes { write_data = wdata', write_sync = wsync' } in
     writeTVar (vcache_writes vc) w' >>= \ () ->
-    return $ w' `seq` do
-        signalWriter vc 
+    return $ do
+        w' `seq` signalWriter vc 
         when bSync (takeMVar mvWait)
         return r
 
diff --git a/vcache.cabal b/vcache.cabal
--- a/vcache.cabal
+++ b/vcache.cabal
@@ -1,5 +1,5 @@
 Name: vcache
-Version: 0.2.2
+Version: 0.2.3
 Synopsis: large, persistent, memcached values and structure sharing for Haskell 
 Category: Database
 Description: