Comment 5 for bug 52613

Hmmm, words like "clearly" and "obviously" tend to be anti-persuasive for me. The various bug tracking systems used by most other Free Software projects don't work the way you're proposing; so while you may be right, it's not clear or obvious.

As I see it, the "anything important in the workflow" generated by the duplicate system is:
(a) a single live discussion of the bug (with discussion in any duplicates stopping, except for the topic of whether it's really a duplicate); and
(b) a single live description of the bug, which is expanded/narrowed/clarified over time (using information from duplicates, if applicable) as the bug becomes better understood. (Granted that the UI for editing the description is clunky right now.)
The duplicate system practically guarantees that everyone involved will be looking at the same bug report, which is a benefit if there are either economies of scale or network effects in more people studying any bug report.

With the merge system there would also be either an amusing disparity between the number of open bugs and the number of reports in a listing of those bugs, or a semi-arbitrary decision about which of a set of equivalent bug reports should be shown in a search listing.

I do agree with you that Malone's "Affects" lines wouldn't present any barrier to a forcemerge-based system -- with a few extra heuristics, like "In Progress" always trumping "Confirmed" regardless of which report was earliest.