OTP 24 overlay: resolving code:which/1 non‑determinism in repeatable development environments

Goal

Build a Docker‑based CI pipeline that can run an Erlang release on multiple OTP releases (23 and 24) while keeping module resolution deterministic.

Constraints & Uncertainty

OTP 24 introduced the overlay mechanism, allowing partial patching without a full system restart. However, the code:which/1 resolution order changed between OTP 23 and 24 when external code directories are present. This can lead to different modules being loaded in the same container image, breaking repeatability. There is no documented flag to revert to the old resolution order, and release_handler scripts must be written manually to downgrade an overlay, which is error‑prone.

Specific Questions

1. What configuration options (e.g., code_path or environment variables) can enforce the OTP 23 module resolution order in OTP 24?

2. Does OTP 24 provide a mechanism or flag to disable overlay loading for a specific release, and if so, how can it be applied in a CI pipeline?

3. What best‑practice release_handler scripts exist for safely rolling back an overlay upgrade when a build container is reused across major OTP versions?