This might be a client thing, but... I'm subscribed to several overlapping communities: !linux on one server, !linux on another, !linux on two others. Same with !lemmy, !commandline, and a couple other communities with the same topic and slightly different membership and/or focus.
Crossposting is a valid and useful tool, but I'm noticing an increase of crossposting where the submitter automatically crossposts to 4 similar communities at the same time. Seems reasonable, and yet... I'm starting to get annoyed by seeing the same post 4 or 5 times in a row. I sort by New and since the posting happens concurrently, they just spam my feed with a page of identical posts.
I could unsubscribe from some similar communities, but the content doesn't exactly overlap and I feel like this is solving the wrong problem. I could decide that automatic crossposting by the same author is "bad behavior" and downvote crossposts, but I feel like this solves the wrong problem and violates a valid use case.
What I think a solution might look like involves a unique ID that persists between crossposts, and a corresponding way to filter s.t. only one post is shown. Some communities are more active than others, and comments on a filtered crosspost would be invisible, so it would be necessary to aggregation crosspost comments, interleaving them under the single, unique, unfiltered post. All comments on all subscribed communities where the post was crossposted would be aggregated; replies to any specific comment would reference the comment in its source community and therefore show up in the right community, for folks who aren't subscribed to multiple duplicate communities.
It requires a more complex solution than it might initially seem. Whatever the solution, I feel as if something should be done, because there's an increasing noise-to-signal ratio resulting from increased crossposting.
The end, though, is the same. lemmy.ml well still want their version, so they can have their own content rules. What you're suggesting is functionally centralization, which is already an issue for Lemmy based on its design; consolidation would aggravate it.
Eventually, lemmy.ml !linux users would want to have their own community to enforce rules programming.dev won't. Diaspora is inevitable. Consolidation fixes the wrong problem - a better solution would facilitate less centralization.