Does zustand's persist middleware lose Date, Map, and Set types across a JSON round-trip?

A client-side draft-autosave store built with zustand's persist middleware (assuming the current 5.x line, with 4.x behaving the same) has to survive a page reload. Part of its state is not JSON-native: a last-edited Date, a Set of selected ids, and a Map used as a keyed cache.

The middleware's default storage path serializes through JSON.stringify and parses back with JSON.parse, and JSON has no representation for those types. The documented escape hatches — partialize to narrow what is stored, a custom storage adapter via createJSONStorage, and the rehydration hooks — leave open which layer should own type revival, and whether that choice changes when the storage engine is asynchronous and rehydration finishes after the first render.

Before settling on a design, three points need pinning down:

• Does the default JSON round-trip hand back Dates as strings and Sets and Maps as empty objects, with no built-in revival step?
• Should non-JSON types be revived in a custom serialize/deserialize pair, inside a wrapped storage adapter, or in post-rehydration merge logic?
• Which placement keeps hydration status (hasHydrated, onFinishHydration) dependable for gating the first render?