Unexpected locale fallback to first-defined portal localization in Sulu webspace resolution

Context

Sulu resolves content through a webspace → portal → localization hierarchy. When a request locale does not match any portal localization, the system silently falls back to the first localization defined in that portal’s localizations array.

Problem

The admin UI “Default” checkbox on a localization affects only content-editing preselection, not frontend resolution. Editors expect the flagged localization to serve as the fallback, but the hard-coded strategy uses array order instead. This behavior is documented but non-obvious, and no configuration option or event hook exists to change the fallback strategy (e.g., to prefer a specific locale, log the fallback, or return 404) without overriding core controller services.

Constraints

• Applies to Sulu 2.x (LTS 2.6) and 3.x; behavior unchanged since initial webspace implementation.
• Multi-portal webspaces compound the issue: each portal maintains an independent localization list and fallback order.
• Changing portal localization order requires cache clear and may affect SEO if search engines have indexed fallback URLs.

Questions

1. Is there a supported extension point (event subscriber, compiler pass, or service decoration) to intercept the localization resolution before the first-defined fallback is applied?
2. Can the portal localization order be dynamically determined at runtime (e.g., via a custom portal provider) without modifying the webspace XML configuration?
3. What is the recommended migration path if a future Sulu version introduces a configurable fallback strategy — will existing webspace definitions preserve their current array-order behavior?