I'm not sure why this would fix the situation.
I wonder if the bug is elsewhere like

The logic behind this is that changing this order impacts how projectDescriptors is evaluated. The expression projectDescriptors ~= { _ ++ gp.descriptors } comes from injectSettings.project, so when it was placed before project.settings, it was overwritten (gp.descriptors is important because it contains the global plugins module).
The projectDescriptors value is then used in the csrExtraProjects task, which is later used for extra projects in lmcoursier.CoursierDependencyResolution#update.

I'm not 100% sure if this is correct, but while debugging, there was a difference between sbt 1.x and 2.x. Right after this change, the global plugins started being loaded.

However, I don't know why the dependency-management tests are failing on CI - locally they work.

I'm rerunning the failed test. Maybe they are just flaky.

I reran them yesterday a few times :( (the same failed each time).
So most likely something is wrong with the implementation or CI.

If we placed injectSettings.project afterwards, then would that mean that the settings that come from user-wide settings would take higher precedence over what's in the settings(...) in build.sbt file?

It looks like it works this way even without changes from this PR (or maybe I misconfigured something).

In the project with sbt version that contains my fixes, when I set version := "2.0" at the very top of build.sbt, and in the sbt file in ~/.sbt/2 I added version := "1.0", the version for the root project was 1.0. When I put version := "2.0" specifically in the root project using settings(...), the version still showed as 1.0.

It behaves the same way in sbt RC8.

I managed to trigger the same exception locally as the one present on CI - I just ran updateSbtClassifiers task in a fresh project with the sbt version that includes the fixes.

I see there's a difference between sbt 1.x and sbt 2.x in sbt.Classpaths.classifiersModuleTask - in sbt 2.x, pluginJars includes global plugin jar, whereas in sbt 1.x, it doesn't. I'll debug this issue further. The symptoms look similar to #8022.

I'm not 100% sure about this because GlobalPluginData#internalClasspath contains not only the exportedProducts but also the value from internalDependencyClasspath - maybe there's some use case where it's required to keep this in the dependencyClasspath.

https://www.scala-sbt.org/1.x/docs/Plugins.html#Global+plugins

The $HOME/.sbt/1.0/plugins/ directory is treated as a global plugin definition project. It is a normal sbt project whose classpath is available to all sbt project definitions for that user as described above for per-project plugins.

If I'm reading it right, I think it's saying that the way sbt encodes "global plugin" is that we will first treat it as a standalone subproject. Then, we will pretend that user's metabuild (project/plugins.sbt) has a subproject dependency (aka internal dependency) to it.

I see.

Do you have any idea for a test that would verify the dependency between the meta-build project and the "global plugin" project?
Even if I make changes, it would be good to have a test that fails with the current implementation.

When I first started sbt 2.x, I moved a bunch of scripted tests to project1 to comment them out. In there there's https://github.com/sbt/sbt/tree/develop/sbt-app/src/sbt-test/project1/global-plugin. Not sure if that currently works, but it might be related?

Are the tests inside project1 not run on CI?
If yes, then I have to move my test ;p

^ thank you, this test is fine – it fails with my recent commit.