Inertia.js partial reload shallow merge replaces nested objects entirely

Context

Inertia.js partial reloads via Inertia.visit({ only: [...] }) perform a shallow merge at the top level of page props. When a requested prop contains nested objects, the entire nested structure is replaced rather than deeply merged. This behavior is documented but leaves developers without a built-in strategy for preserving unrelated nested fields during partial updates.

Goal

Determine whether a page component can safely request a subset of a deeply nested prop (for example, user.profile.settings) without losing sibling keys like user.profile.preferences that the server omits from the partial response.

Constraints and uncertainty

• The framework does not provide a deep-merge utility or configuration flag for partial reloads.
• Server-side implementations must manually construct responses that include all nested keys the client expects to retain, which couples API shape to client merge behavior.
• Using preserveState keeps the component instance alive but does not alter the merge semantics; stale nested data can persist if the server omits it.

Questions

1. Is there an officially supported pattern or community convention for achieving deep merges during partial reloads without sending the full nested object from the server?
2. Can a custom client-side merge be applied via onBefore or onSuccess callbacks without breaking Inertia's internal state management?
3. Does the upcoming Inertia 2.0 roadmap address nested partial data merging, or should teams implement their own normalization layer?