Oh My Zsh plugin load order: missing deterministic sequencing for repeatable environments

Plugin load sequencing

Oh My Zsh sources plugins by alphabetically sorting filenames in $ZSH/plugins and $ZSH_CUSTOM/plugins, ignoring the order declared in the plugins=(...) array. When multiple plugins define the same function, alias, or environment variable, the last-sourced definition wins, producing shell behavior that depends on filesystem ordering rather than explicit configuration.

Repeatability constraint

A development environment pinned to a specific Oh My Zsh commit can still exhibit different plugin load sequences across machines if the underlying filesystem returns directory entries in a different order, or if a CI image pulls a newer upstream release that changes the plugin set. No core mechanism exists to declare a desired load order or to resolve conflicts between plugins that overlap in namespace.

Open questions

• Is there a supported pattern for enforcing a deterministic plugin load sequence without maintaining a fork of lib/init.zsh?
• Can ZSH_CUSTOM be structured so that plugin filenames encode a priority that survives upstream updates?
• What is the recommended approach for teams that require identical shell behavior across local workstations and ephemeral CI runners?