I've seen this before and now again in http://qa.drupal.org/pifr/test/471168. So I looked into it.
When you enable xdebug, you get the stack trace, which shows something like this:
PHP Fatal error: Class 'Insert' not found in /core/modules/system/lib/Drupal/system/Tests/Menu/TreeAccessTest.php on line 108
PHP Stack trace:
PHP 1. {main}() /core/scripts/run-tests.sh:0
PHP 2. simpletest_script_get_all_tests() /core/scripts/run-tests.sh:54
PHP 3. simpletest_test_get_all() /core/scripts/run-tests.sh:336
PHP 4. class_exists() /core/modules/simpletest/simpletest.module:484
PHP 5. Symfony\Component\ClassLoader\UniversalClassLoader->loadClass() /core/modules/simpletest/simpletest.module:0
PHP 6. _drupal_error_handler() /core/modules/simpletest/simpletest.module:251
PHP 7. _drupal_error_handler_real() /core/includes/bootstrap.inc:2248
PHP 8. _drupal_log_error() /core/includes/errors.inc:77
PHP 9. watchdog() /core/includes/errors.inc:212
PHP 10. dblog_watchdog() /core/includes/bootstrap.inc:1797
PHP 11. Drupal\Core\Database\Connection->insert() /core/modules/dblog/dblog.module:148So what happens is this. We are entering the classloader, during loading the class we notice something that's not right, in my case a dumb strict error. PHP error handling is triggered, dblog_watchdog() is invoked and that tries to create an INSERT query to log the error to the database. That goes all the way down to Connection::getDriverClass() which checks if ""Drupal\\Core\\Database\\Driver\\{$driver}\\{$class}" exists. Because we are already in the process of loading a class, PHP doesn't attempt to invoke the classloader again, assuming that this could result in an endless loop or something.
Then the bogus fallback comes into play that falls back to just "Insert" (The fallback logic should be Drupal\Core\Database\Query\$class, which would also mean that we wouldn't need those "dumb" empty Driver classes). That is returned to the caller which tries to instantiate that class and... kaboom.
Because we are however still in the error handler within the classloader, the fatal error is shown on the line where the error was triggered.. the closing } of whatever class caused this.
Isn't this an interesting pile of .... fun?!
I do not have the slightest clue on how to fix this. The fallback logic should be fixed but that will end up with the exact same result. Any ideas?