Packaging Kubernetes for Debian

Yeah that is definitely true for Rust -- and I would argue this is because Rust grew the idea of strong versioning very early on (before Go modules you could argue that this wasn't a first-class feature in Go for most of it's lifetime). In theory Go modules might improve this situation, but to be honest I'm fairly skeptical that this will change enough Go projects that it will allow us to change how we would package the majority of them.

> Maybe someday we'll have the ability to use Rust APIs across a shared library boundary (sure, you can technically do it today, but limiting yourself to the C ABI for inter-library calls and compiler checks is quite restrictive in the Rust world).

This would make packaging more efficient in practice (only compile libraries once and reuse the compiled files as much as possible) -- and would be great to see -- but in principle the organisation of packages doesn't need to mean that library packages are actually distributed as compiled code. If you have a package for each (library) crate dependency which is used by a binary crate you can still do the actual compilation in the final binary. In this instance the issue is more about being able to represent crate dependencies using the distribution's method of representing such dependencies (BuildRequires in RPM).