Persistent Perl interpreter accumulates mixed old and new code after repeated do FILE

The goal is to update code in a small, long-running Perl application without dropping the listening socket or interrupting in-flight requests.

Perl's require records a path in %INC and skips re-execution on later calls, so it cannot hot-swap changed definitions in the same interpreter. do FILE re-executes code but does not maintain %INC the same way, and repeated execution can leave duplicate package definitions, stale symbol-table entries, or a mixture of old and new subroutines. XS modules, fork behavior, thread support, and signal handling vary by Perl build, so the safe cutover path depends on the target interpreter.

Should the migration use in-process reload with strict single-loader ownership and drained workers, or start new Perl processes and transfer the listening socket? Which target Perl build characteristics determine whether socket handoff is viable? What checks detect mixed old and new symbol-table state before retiring old workers?