On Google+, it was possible to individually block specific profiles.
This meant that the blocker wouldn't see the blockee's posts and the blockee wouldn't see the blockers, which is pretty much expected behaviour.
But on third-party threads, if a blocker/blockee were both commenting, others could see their comments but they'd be mutually invisible. As the platform matured and the number of such blocks increased, this reached a point where that platform behaviour became common enough that it was frequently commented on. If the thread host isn't sufficiently diligent in their own moderation (effectively each post author is moderator of that thread), it's also possible for such discussions to devolve quickly.
I guess Usenet would be another case where individual killfiles were often applied.
This isn't quite the same as your proposal, but it does raise the challenge that if there are multiple moderation regimes occurring, there is no canonical view of a discussion, leading both the potential confusion over what has or hasn't been said, and potential derailment (or similar behaviours) if a sufficiently disruptive participant is not universally blocked. The canonical flamefest after all is often just two profiles / participants responding endlessly.
Diaspora* is similar to G+, except that on third-party threads the blocks don't work, so that if A blocks B but C does not block B, then A and B will see one anothers' comments on C's posts / threads. This ... can be frustrating.
Oh, and the post-author-as-moderator model also somewhat resembles what you'd suggested, in that you could choose to participate on a particular profile's posts given that profile's moderation practices. I found that there were several people who did an excellent job of this, and who were quite affective, in effect, salon hosts, which was how I saw the G+ moderation model over time. This differs from what you suggest in that every participant on those threads had the same moderation experience, but it was possible to choose moderation practices based on which profiles' threads you chose to participate on. And I'd definitely avoid poorly-moderated hosts.
I think the difference between what I'm suggesting and all of these is that by selecting a mod, you're selecting a auto-updating block list. Behavior would tend toward consistency as good mods would be popular and there is nothing keeping a mad mod around over than momentum.
There have been such blocklists circulating for some time on other platforms, notably Twitter. Those could become problematic where they were adopted without review, and/or those who were listed lashed out all the harder against those they thought had promulgated the lists.
I became aware of this when use of the lists and/or the drama that accompanied them leaked into the Fediverse a few years ago.
The Fediverse also effectively works in ways as a "subscribe to moderation policies" network, in that each individual instance has its own moderation policy and blocklist (individuals and instances), which is probably closer to what you've described than any of the other examples I've noted. This ... has some benefits and frustrations as well, particularly as swapping mods isn't as frictionless as your ideal version would be. There's also the "broken threads" dynamic, similar in ways to that seen on G+, though with the Fediverse (a closer analogue to Twitter) there's no top post, and no original-author-as-moderator dynamic, which means that if a particular thread is interrupted by a blocked profile/instance, the thread as a whole tends to fragment. Devs are aware of this and may be looking at other ways of aggregating threads, e.g., by having multiple "refers-to" type headers (see the Mutt email agent's threading model for more on this).
Most places can hide posts and block users at the user level, so why not select which mods can do that for you?