nativeBuildInputs, buildInputs, propagatedNativeBuildInputs, and propagatedBuildInputs are horrible names:

• Word order + capitalization impedes easy grepping
• native is vague wrt cross compilation
• build time vs run time usage is unclear
• both the host platform and target platform of dependencies can be varied, so in fact there is 2 axis of "native" vs "foreignness"

In #26805 I do add 4 more sorts of dependencies giving us:

A disadvantages of these names, per the comments below, is for the vast majority of deps the target platform is irrelevant---my names are unintuitive and noisy in this case.

N.B. I'd love to structure things purely when the deps are needed---run time or build time---which is a pretty understandable concept even for those who have never heard of cross compiling. But this just isn't correct (yet). Firstly, it isn't enough granularity---see when dependent's host = depender's build, there's 3 possible target platforms. Worse, host=host dependencies may be used in all possible ways: only at build-time (static linking), only at run-time (dynamic loading of plugin library), or both (linking and headers).

A completely different approach would be rely more on language-specific builders: For C, let people think in terms of headers (and pkg-config files, etc) and libraries (dynamic or static), and then C-specific infrastructure would take care of everything behind the scenes regarding propagation and multiple outputs. I should probably elaborate this approach more fully in the another issue or RFC.

Split out from #4855

CC @dezgeg @edolstra