Consider these requirements:

a >= 1 ; sys_platform == 'linux'
a < 2 ; sys_platform == 'darwin'

with a==1.0.0 and a==2.0.0 available in the registry.

(These are captured in this packse test.)

Even though the version constraints are non-conflicting, because the marker expressions are non-overlapping, this will actually provoke a fork in the universal resolver. The fork means that the a >= 1 requirement is free to choose, say, a==2.0.0 if it's available because the fork exists in isolation from the a < 2 requirement. However, if no fork were to happen, then both the a >= 1 and a < 2 requirements would be active simultaneously such that a==2.0.0 couldn't be chosen. So in this case, there exists a resolution without forking, but it is distinct from the resolution we get if we fork.

I think we could detect this case by looking at whether the version constraints themselves are conflicting. That is, if there exists an overlap in the version constraints, then we don't fork even if the marker expressions are non-overlapping. I think a decision like that would be predicated on the idea that it could be possible to find one resolution that works across multiple platforms. But it might not be possible. It feels like forking in this case, even if it isn't always necessary, results in more freedom for the resolver to find a resolution. But... maybe it's surprising to users in real cases.

I'm overall not quite sure what the right behavior is here. My sense of things right now is that this shouldn't block shipping, but I'm happy to have my mind changed on that!

Original discussion: #4339 (comment)