Problem/Motivation
The first line of index.php is to instantiate the autoloader. This is Drupal's primary class loader. Settings.php can then swap it out for a different one (e.g., add a decorator) by setting its $class_loader variable. After DrupalKernel::boot() is finished, this class loader is available to all code via \Drupal::service('class_loader').
Ideally, code that runs before DrupalKernel::boot() is finished would also have access to this same class loader. This primarily includes code that's part of the database system, such as the static methods of the Database class, and the code within database drivers (core and contrib). However, it also includes code that's run by settings.php itself (as well as sites.php in the case of a multisite). And, in the case of a cold start after a cache clear, this could also include all code that's involved in compiling the container, such as all of core's and contrib's service providers and compiler passes.
The reason it would be ideal for all Drupal code to access the same class loader, regardless of when during the bootstrap/request it runs, is so that if settings.php or other code does decorate or mutate this class loader, it affects all classes loaded by Drupal. For example, if there's code that adds logging, or that converts relative paths to absolute paths, or relocates to alternate paths, these changes should apply to all of Drupal's not-yet-loaded classes. Early bootstrap code shouldn't have to resort to registering a separate autoloader, because then anything added to that autoloader wouldn't receive the changes made to the primary autoloader.
Steps to reproduce
Proposed resolution
Add a \Drupal::classLoader() method that can be called at any time during the bootstrap / request.