So the problem with additional settings.gradle is that those are not supported by gradle CLI. I.e. if you just run ‘gradle xyz’ in a folder with a settings.gradle, then gradle will assume this folder contains the root project. For cross project configuration, you would have to somehow replicate the project structure from the “true” rootproject, recursively. Similarly when running gradle from the project root, the nested settings.gradle will not be evaluated.
If I understand you correctly, what has been done is having multiple level1 gradle root projects with their settings.gradle each, and a root level0 project which has a settings.gradle that either replicates the other settings.gradles, or even loads them manually. This would probably be a very dirty approach since paths like “$rootDir/config” would depend on the execution context, and thus more hacks would be required. I do not know whether it is acceptable in the gradle community to break existing systems with new gradle minor versions if they have relied on unspecified behavior.
A nicer approach would be to create a suitable defined behavior for this use-case and deprecate the existing behavior such that only a deprecation warning is printed when a subproject has it’s own settings.gradle. Another approach would be to have opt-in strictness (like cmake policies) or opt-out strictness such that breakage with a new gradle version can be easily repaired.
I do not understand how empty projects would help with parallel task execution. If you can give more details on this use-case I can try to think of something better.
In any case warnings can be implemented hopefully without annoying gradle users, as a first step. I can look into creating a pull request.