Okay, I’m going to reason about how kind=static vs kind=dylib can be useful in the scope of the Windows world and DLLs.
Let’s say you have a static C library called foo. It has global state so you want to make sure there is only a single instance of it. The linker is invoked to create a binary each time a .exe or a .dll is produced. If you pass foo to the linker for a given binary, it will gain its own instance of foo. If you have a Rust library that uses foo built into a .dll, and then you use that .dll in a .exe, you really want to make sure there is only a single foo. Therefore foo should not be passed to the linker for the .exe and it should only be passed to the linker for the .dll containing the Rust library that links to foo. foo will in turn be exported from that .dll as needed. This is the situation where kind=static makes sense, but notice that bundling foo into the .rlib is not the solution, the real solution is simply making sure foo is only passed to a single linker invocation and re-exported for use by the other binaries.
Now suppose we have a C library which does delegate to a .dll. In this case you don’t have to worry about global state since it is already a .dll, therefore you can use kind=dylib and just happily pass it along to each linker invocation and everything will turn out just fine.
Maybe on non-windows bundling is the answer, but in the windows world, bundling solves absolutely nothing. The real solution is just making sure global state isn’t duplicated across multiple binaries.