Passport 0.6 deserializeUser error handling divergence between done(err) and done(null, false)

This question addresses how Passport 0.6's deserializeUser callback should distinguish between a missing user record and an operational failure when reconstructing req.user, given the framework's changed error propagation model. The 0.6 release shifted authenticate middleware error handling from throwing to next(err), which alters how strategy failures propagate through Express error middleware. Concurrently, deserializeUser may call done(err), done(null, false), or done(null, undefined), each producing distinct req.user values and downstream authorization behavior. No built-in schema or session versioning exists, so the chosen pattern directly impacts session durability across deployments.

• When should deserializeUser invoke done(err) versus done(null, false) to maintain consistent req.user state?
• How does the authenticate middleware's next(err) change interact with strategy-level errors in deserializeUser?
• What is the typical pattern for migrating existing sessions when the deserializeUser contract shifts between Passport releases?