Custodian memory limit accounting varies by Racket backend

Designing per-evaluation resource containment in Racket with custodians and racket/sandbox requires a memory cap that reliably triggers an out-of-memory condition inside the contained computation while leaving the host process intact.

The documented mechanism uses custodian-limit-memory and call-with-limits/with-limits. Memory accounting is described as approximate, and allocations shared with the host or outside the custodian may not be charged fully. Time limits depend on wall vs CPU setup and blocking foreign calls may not be interruptible promptly.

An unresolved decision is how limit tuning should account for backend differences. Accounting detail for custodian-limit-memory is reported to differ between the Chez Scheme backend and the legacy BC backend, making a single limit value backend-sensitive.

What documented accounting differences exist between Chez and BC backends for custodian-limit-memory? How should a memory limit be chosen to provide consistent guardrail behavior across backends? Are there documented constraints on what allocations are included or excluded from the custodian charge?