First commit bash+manual, second one automated with this:

<?php

$srcDir = __DIR__.'/src/';
 
foreach (new RecursiveIteratorIterator(new RecursiveDirectoryIterator($srcDir,  RecursiveDirectoryIterator::SKIP_DOTS), RecursiveIteratorIterator::LEAVES_ONLY) as $newFile) {

    $class = substr($newFile, strlen($srcDir), -4);

    $oldClass = 'Twig_'.strtr(substr(file_get_contents($newFile), 2, -5), '/', '_');
    $newClass = 'Twig\\'.strtr($class, '/', '\\');
    $oldFile = '/lib/'.strtr($oldClass, '_', '/').'.php';

    $ns = substr($newClass, 0, strrpos($newClass, '\\'));
    $newClassBase = substr($newClass, 1 + strrpos($newClass, '\\'));
    $dots = str_repeat('/..', substr_count($newClass, '\\'));

    file_put_contents($newFile, <<<EOTXT
<?php

namespace $ns;

require __DIR__.'$dots$oldFile';

if (\\false) {
    class $newClassBase extends \\$oldClass
    {
    }
}

EOTXT
    );

    file_put_contents(__DIR__.$oldFile, <<<EOTXT

class_alias('$oldClass', '$newClass', false);

EOTXT
        , FILE_APPEND
    );
}

Great move. I don't understand why we need to create an alias and a subclass for each existing class ?
Also, what is this trick with if (\false) {} ?

That's a good question :)
This is required to have Composer generate its class maps!

@GromNaN using a fully qualified name to access false is to allow resolving the condition at compile time (and so let OPCache drop dead code), instead of going through the fallback logic to determine whether a constant has been defined to overwrite false (yes PHP 5.x allows such thing)

Wouldn't it be simpler to just add a files entry to autoload in composer.json and define all the class-aliases there? It's one file hit, instead of one per class. Just wondering :-)

whether a constant has been defined to overwrite false

@stof How is that possible? I couldn't find a way to do so. I get one of these errors.

Fatal error: Cannot redeclare constant 'false'
Notice: Constant false already defined

Nvm, I got it:

namespace Foo;
define('Foo\false', true);
var_dump(false);

Wouldn't it be better to add the new classes together with scalar typehints?

@mindplay-dk the heavy call is the autoloader, not the file hit (when opcache is activated of course), so I prefer doing it this way because it makes it easy to then move gradually to using namespaces internally.

@Tobion I prefer keeping one topic per PR. This one is on branch 1.x btw, so php5.3 mini.

Thus, using files to register all aliases would be much more costly: this file would be included in all requests (even when not using Twig), and would trigger autoloading of all Twig classes (due to the target of the alias), even when you don't use most of them (in prod, most Twig classes are not used at runtime as templates are cached and lots of classes are related to the parser and the compiler)

Thank you @nicolas-grekas.

Note that before tagging 1.34/2.4, we should make sure that we don't want to rename more classes. Doing it while adding the namespaced aliases makes it easy.
I'm thinking about e.g. Twig_Environment, which could be renamed Twig\Twig.
Trying to move Symfony to namespaced Twig before tagging could help spotting the cases where this might be useful.

Could you give an 3v4l example about if (\false)? I'm curious :)