New feature on lib.rs: in the footer similar crates are split into "Related" and "See also" groups.
The "Related" ones are crates that have crate owners in common or are in the same repository, and additionally to display a more relevant list they're filtered to have something else in common, like the name prefix or home page URL.
The "See also" group is just crates with similar keywords which didn't make it to the other group.
There were sorted by similarity. I've changed them to sort mostly by their ranking. Ranking already includes signals such as outdated deps and loss of popularity. serde_derive_internals is a tough case, because it has more traction and maintenance than an average crates-io crate
Unfortunately, I don't have any side channel to directly deprecate crates. You can yank them. You can remove them from serde-rs repository plus optionally move them to an "archived" repo on GitHub. You can add badges.maintenance.status = "deprecated".
Perhaps accept a bit of metadata in Cargo.toml? Another example here is time: the related crates are time-macros, time-macros-impl, time-formatting, and time-core. None of these are ever intended to be used on their own — such a use case is officially unsupported. Even then, time-macros is the only one that's active. time-macros-impl is for an old version of time and is no longer needed, and the latter two are merely reserved names for a future split into multiple crates.
I think a specific categories value would suit the "this is an internal crate" use case well — it's describing a purpose the crate serves.
For obsolete crates, I think it would make the most sense to publish a final version with suitable README updates ("this is no longer used since version ") along with other metadata, but people are less likely to bother to do that at all, so a yank-like mechanism might be interesting for that but I'd guess it would see less use than the other feature.
If people won't bother to publish updated metadata, what makes you think they'll bother to do some "yank-like" thing? (I sure hope you're not talking about actual yanking, that would create issues in the ecosystem for no good reason)
My reasoning is that a single command is simpler and less disruptive than preparing a new version (with bumped patch version number) to publish. I don't think it would see enough use to be worth implementing though.