Linear memory growth limits and host-call atomicity

WebAssembly linear memory is defined as a sequence of 64 KiB pages. While the memory.grow instruction is atomic within the module's execution, the specification does not provide transactional guarantees for operations that interact with host-imported functions.

When a module attempts to expand memory and reaches the defined maximum—typically the 32-bit limit of 4GiB unless the 64-bit memory proposal is actively supported—the execution traps. However, if this trap occurs after several host calls have already modified external state or performed writes, there is no native core-level mechanism to roll back those changes or prevent duplicate side effects during a retry logic.

How should a host runtime manage the state of linear memory if a trap occurs mid-sequence during multiple host imports? Is there a standardized approach to ensuring idempotency for host calls when memory growth fails due to limit exhaustion?