Paul M. Jones a extrait le concept `declare(strict_namespace=1)` du RFC sur l'autoloading de fonctions pour en faire une proposition indépendante intitulée "Strict Namespace Resolution". Le RFC est disponible à https://wiki.php.net/rfc/strict-namespace et est accompagné de la pull request https://github.com/php/php-src/pull/22736. Ce mécanisme est conçu comme une aide à l'initiative d'autoloading de fonctions, mais il n'en est pas une condition stricte.

La directive permettrait aux développeurs de renoncer au comportement de fallback actuel de PHP, où un nom de fonction ou de constante non qualifié dans un namespace est d'abord recherché dans le namespace courant, puis, s'il n'y est pas trouvé, dans le namespace global. Avec `declare(strict_namespace=1)` activé, ces références ne se résoudraient que dans le namespace déclaré, obligeant ainsi à importer explicitement ou à qualifier pleinement les symboles globaux.

La discussion sur la liste PHP internals a beaucoup porté sur le nom et la portée. Rowan Tommins a fait valoir que le libellé "strict_namespace" est trompeur, car la directive ne valide pas la correction des namespaces ; il a proposé des alternatives comme `legacy_name_fallback` ou trois modes explicites (global-only, current-namespace-only, fallback). Tim Düsterhus a suggéré `declare(global_fallback=0)` comme option plus claire, tandis qu'Alex Rock a évoqué `disable_root_ns_fallback=0|1`.

Ilija Tovilo a remis en question la valeur globale de la proposition si le fallback historique n'est jamais supprimé ou déprécié, notant que les utilisateurs qui optent pour la directive n'obtiennent rien qu'ils ne puissent déjà imposer avec un linter. Il a également esquissé un autre modèle dans lequel les noms non qualifiés renvoient toujours au symbole global, les symboles locaux étant accessibles via des imports `use` explicites. Paul M. Jones a répondu que la motivation principale reste d'atténuer le cas rare du « shadow global » dans l'autoloading de fonctions, et que la directive reste délibérément optionnelle.

Michael Morris a soulevé une préoccupation pratique concernant l'application de la directive à de nombreux fichiers sans avoir à l'ajouter en haut de chacun d'eux, ce que Rowan Tommins a qualifié de problème de conception plus profond de « package natif » ou de « module », dépassant le cadre de l'autoloading. Tim Düsterhus a également signalé que les analyseurs statiques et les EDI devraient reconnaître la directive pour émettre des diagnostics pertinents.

Des RFCs antérieures sur le même sujet ont également été mentionnées : « Fallback to root scope deprecation » de 2017, qui a été discuté mais jamais soumis au vote, et « use_global_elements » de 2020, qui a été rejeté.