We could do all merges by hand, then we can do whatever we like to the commit subject. Then again, a lot of work. Maybe we should rethink our reasoning behind wanting to use the merge commits. It was to lower the barrier, so that people wouldn't have to (always) write (absolutely) proper commit messages.
Since a merge only pulls in changes, and the action actually happens in the commits on a branch, this might be the wrong approach… Even for merge conflicts - those should be resolved by merging the target into the feature branch, not while merging the feature into the target branch.
Now, considering the upmerges, those will never be able to inform about all that is merged. There might be one, three or a dozen changes being merged, that won't fit into a single subject line anyway. That's why most git tools will just list the sibject lines in the body of a merge commit message.
All that being said, by now I think our best bet is to try to get proper commit messages to begin with (yes, why not let people force push on their first two, three PRs until the get the hang of it?). Then we can create change logs by ignoring merges (or not) as we see fit.
And in the end, most people would probably be totally fine with a simple compare view on GitHub, with all the navigation into the code it provdes. A lot of libraries and projects use nothing more for their change logs.