What prevents Cargo from adding `[bench/bin/example-dependencies]`?

One thing that bugs me is that a single package (one Cargo.toml file) with multiple crates (AKA targets, products, bins/benches/examples) looks roughly similar to having a single workspace with multiple packages. It's like two zoom levels of the same fractal.

There's pressure to add more separation between crates of a package, as well as pressure to add more integration between packages in a workspace.

If we extrapolate these trajectories, Cargo will end up with two almost equal ways of making multi-crate workspaces, but with historical small differences between them that are going to cause confusion and debates which one is the right one.

So I'm wondering whether these two can actually be made the same thing, in a direct way. What if workspaces could be freely nested? What if lib+bin packages were retroactively explained to be workspaces containing a lib-only package and a bin-only package, merely defined using "syntax sugar" of [lib] and [[bin]] in one file instead of separate Cargo.toml files for each.

Imagine that you could start with a lib+bin Cargo.toml package, but once you needed to have separate dependencies for the bin, you would make a full cli/Cargo.toml for the binary with its unique dependencies and features, but some yet-to-be-invented inclusion/inlining mechanism would let you merge it back with its lib crate to keep it behaving just like before, like single lib+bin package.