While this is a little weird, it doesn't do anything bad and I'm not sure it's really worth the complexity of preventing. In particular, we've had a couple of cases where the original task is re-opened and then legitimately re-merged later, and it would prevent this workflow. The un-merge/re-merge workflow seems more useful than the double-merge workflow seems weird, to me.

If the "merge" operation was stronger and more formal (and had a formal "unmerge" operation) or double-merging actually did bad stuff, it would make more sense to prevent it. We may make the operation stronger in the future (we recently took a step in that direction and made the merge a formal transaction -- previously the operation just posted a comment) so we might end up here eventually, but there aren't any immediate plans to do that.

I think the most likely motivation for a more formal merge in the near future would probably come from Ponder -- I want to let questions in Ponder be marked as duplicates of other questions, and probably show those merges very prominently. If that feels good, we might mirror the UI in Maniphest for consistency (for example, show a colored "This task was merged into ..." banner at the top of the screen) and that might motivate a more formal merge operation.

Today, we don't even really keep track of whether a task has been merged into another task (we could figure it out, but we don't actually write a formal, unambiguous marker anywhere) so preventing double merges in a reasonable way would be a fair bit of work (not just a trivial check + error message).