I agree with @kornel that the conceptually more simple approach lies the other way: rather than introducing another layer of complexity, we could instead strengthen the abstractions we already have and fix their leaks. From the list of reasons for wanting to have multiple libraries per package, the latter three are directly fixed by having things in different crates.
While the initial post seems pretty extensive in terms of its discussion of a potential solution, I found it a bit light in terms of talking about the problems or use cases that need to be addressed. The second post discusses a concrete use case, but seems to mainly revolve around the proc-macro issue.
As the author of a somewhat popular custom derive crate, I definitely feel the pain about not being able to distribute procedural macros as part of a larger library. I also agree with @bascule that publishing a number of libraries from a workspace is painful today. However, I don’t think sublibraries are the best way to address these problems.