I think I experimented a while back with collapsing merges like you say, but IIRC the changelog was then missing important commits that were made in, e.g. feature and bug-fix branches.
My current practice is to style the actual merge commit differently, but I do include the commits that come along with the merge because the merge commits usually only say unhelpful things like "Merge 10.1 into 10.2" which doesn't particularly describe what is included in the merge. If a merge commit summary is especially helpful it will say something like "Merge pull request #397 from MariaDB/bb-10.2-MDEV-12067", but even then you can't tell at a glance what the merge was about.
That said, if I exclude the latest MariaDB 10.1 release from 10.2 release changelogs then 10.2 changelogs have a bunch of "Merge 10.1 into 10.2" commits with no indication of what was included, but at least in this case we do have the 10.1 changelogs that people can refer to if they're interested, and I could make it standard practice to always add a link to the latest MariaDB 10.1 changelog somewhere on a given 10.2 changelog page (maybe wherever there is a "Merge 10.1 into 10.2" commit).
What if I filter out the latest MariaDB 10.1 release tag when I generate the changelog (e.g. with ^mariadb-10.1.25)? It will filter out more than just xtradb-related commits, but everything it filters out is already available in the 10.1 changelog.