Yes, that’s clear now but it was not before. From my POV settings is not another project, yet it’s a different context. Thus resolving configurations from a_different_context other than the owning project would be a better wording in the docs IMHO.
Efficiency is not my goal, UX is. Enforcer rules should be activated all the time, even if that affects build speed. Caching would certainly help but that requires updating the code to take advantage of that. Something that can be looked at once Configuration Cache is no longer incubating and becomes mandatory.
Hooking a enforcer task to the check task for example could work to move configuration resolution to later in the build, however that requires explicit invocation of enforcer, or check, or another task (such as build) that will invoke check as part of its dependency chain.
If there were a task that’s always invoked (say validate which would “mimic” Maven’s validate lifecycle phase, in the sense that’s invoked early in the build) then an enforcer task could be attached to it. I don’t think there is such a thing in Gradle right now, is it?
Another option would be to always inject the enforcer task into the Task Graph and have it placed as early as possible, though to be honest I don’t know if that’s possible without internal APIs.