Well, correct me if I'm wrong, but installing 15063 would then match one of the checks, and become the selected SDK, so be expected to work fine, right?

I think (not sure) that the issue with my Win8/10 workers is they only have the later 16299.  So in that case the build process is trying to enforce 10586 as a minimum (due to not finding anything else) which can't work.  Assuming I'm interpreting the new WindowsTargetPlatformVersion definition correctly).

When you say the "others were going to fail too" I don't think that's correct in all cases.  That is, the installed version doesn't match the checked versions, but it's later, so it could work fine.  And in this case it's the only version available so the default build tool selection is fine.

I'm guessing Jeremy's case was having older (not workable) versions and still not matching one of the checked versions, in which case the build default of oldest would fail.  And yes, in that case enforcing a missing version is no real difference since both options fail.

Not sure if solving both cases is possible, but at least letting the build tool default to an available SDK if no match is found seems more conservative.  It might still fail, but there are cases where it won't.  And it seems more likely over time that someone may only have a later SDK than that they'll have an earlier one or a guaranteed match to those being checked.  Or if we want to enforce specific versions, publishing them and forcing the build to fail hard would be an option too.

I don't think the difference in registry vs. folder checks is an issue, at least not for me.  On the Win8/10 workers, both the registry and filesystem are in agreement - the only thing available is 16299.

I'm also not sure if it's possible, but it would be great to have some output somewhere about the selection.  Right now there's nothing in the compiler stage output of a working vs. failing build to indicate why they are behaving differently.  But that's probably a separate topic.