I largely echo @Aciid's reply here, but let me frame it a little differently.
First, I absolutely agree with you that #1 & #2 "can be" tackled as two sides of the same coin. However, I very intentionally believe that we should not do that.
Here are my main reasons for wanting to treat them as orthogonal:
- I have largely been working towards a world in which #1 is automatic, safe, secure, and transparent to users. I want high performance builds with excellent caching to be something that "just works" and users don't need to think about, to the extent possible.
- From a design space perspective, what a lot of it comes down to is whether a single package can be both source and binary. If that is allowed, it alters the design space for #2.
- As a concrete example, the proposal @FranzBusch @Braden_Scothern and I are hashing out introduces a new target type for binary targets. That works, because it is orthogonal to existing targets. If we wanted to support both dual representations, we would have to have a different (and I believe more complex) API.
The combination of these two points means that I believe we will get the best user experience by treating these as separate.