With git cherry it is possible to check which commits have been already applied to another branch, typically the upstream. However, this returns only non-merge commits. Also git log --cherry ... excludes merge commits, since it implies --no-merges.
If a commit has been cherry-picked with -x, then the source revision is included in the commit message, so it is at least possible to git log --grep for a revision and check if it is already present.
If -x has not been used when cherry-picking, how can I robustly detect if a merge commit has been already picked to a branch?
For good reason: you can't blindly cherry-pick merges, it's always cleaner and safer to cherry-pick the merged commits instead of the merged result.
Still, this is Git. You can cherry-pick the result's diffs from one tip or the other, but be aware that that's going to bake in any conflict resolutions, and those are specific to that merge, i.e. incorporating both histories since the merge base, not just one, and so not something you want to casually rebase like this.
If you've somehow found yourself backed in to having to do this anyway, it's not hard to extend what
git cherryautomates for you and generate patch ids for the diffs you'd have used,and look for commits in the other history with the same patch id, but I'm having a very difficult time imagining what anyone would even think they're gaining by doing this. Erasing Git's records of merges like this might not quite be up there with lying to your compiler, but it's a niche usage at best, disabling almost all of Git's content-tracking machinery and leaving you with a lot of work doing manual record keeping and manual spelunking in and deduction from those records to make up for the Git records you put so much effort into erasing.