Description:
------------
Would it be possible to modify include() and require() to take a second argument specifying the namespace scope that the included code will execute in.  If the argument is omitted the code executes in the root scope it always has. Any namespace paths in the file would be sub-namespaces of the namespace path specified in this new second argument.  Examples:

include('file.php', __NAMESPACE__); // exec in current namespace
require('other.php', '\\MyNamspace'); // exec in 'MyNamespace';
require_once('again.php'); // exec in global namespace for backward compat.

This change addresses a minor problem I hit while using namespaces with my template system. The template files are included into the function scope, but the code in those templates loses the namespace of the function that made the include call. I could namespace the templates, but they are primarily html files and so having a namespace header on them looks ugly.

I do not know if the loss of namespace is considered a bug in and of itself.

One powerful application of this addition is it would allow autoloaders to load classes into different namespaces. Instead of declaring the namespace of the class in the class file statically, the autoloader could determine the namespace it needs to load the class into to satisfy the path. This would also allow for dynamic subclassing of projects.

Consider framework with namespaces \Framework and \Project.  The former contains the default work files of the framework and the latter those of the project.  A call for a new class is issued to the autoloader from code executing in \Framework space looking for the Page class.  The autoloader is programmed to check the project files first to see if there's an override.  There is.  The file starts off with "class Page extends \Framework\Page" If include("Page.php" "\\Framework") is allowed then we will get a second call to the autoloader for the original framework file, but the path will be "\Framework\Framework\Page". With a little effort in the autoload writing this could be resolved and code execution could continue.

Not going to say how easy it would be to *debug*... but it does add a lot of flexibility into the mix.