I have a similar issue. In my case, there is a package called GraphicsRenderer causing problems. During build, either Xcode Cloud or a fresh local build (done after xcodebuild clean), xcodebuild will claim it finds a new package called graphicsrenderer (the case matters here), but new package is not allowed when automatic package resolution is disabled. Then a fatalError is triggered and the build failed.
Below is all speculation. I believe due to some bug in either Xcode or SwiftPM, xcodebuild treats GraphicsRenderer (which is the name recorded in my Package.resolved) and graphicsrenderer, which is the default name derived by Xcode, as two different packages. By the way, I failed to modify my Package.resolved to make Xcode believe they are the same thing. Notice that locally, a second run can happen smoothly, probably because some cache that helps Xcode correctly identify the two as the same thing.
I found a not very practical workaround when attempting to creating a minimal case to report to Apple. That is, recreating your Xcode project using Xcode 14. It seems that a version 2 Package.resolved has been put in use since Swift 5.6. In that format, I can see there is an identity for each resolved package, and GraphicsRenderer has that field set to graphicsrenderer. I no longer face any issue. But I cannot get xcodebuild to generate a version 2 Package.resolved for my existing. My guess is that for any Xcode project, there is a minimum compatibility specified. My old projects were created with Xcode 13 and thus locked the version 1 Package.resolved.
By the way, I have zero idea when this issue might occur. It certainly won’t happen for Apple packages, which all adopt an all lowercased naming such as swift-markdown. But this didn’t happen for GRDB and many other packages with capital letters.