On November I opened an issue with the Plastic team regarding this. I provided a couple of reproduction paths, and explained the problems they caused (for our team, in particular). The problems are empty changesets in the xlinked repo, and updated xlink changeset ids when merging unrelated changes into main turning things into a spiraling chaos of empty merges and incremented changeset values.
I was told the issue has been communicated to the development team, I was asked for some more info, and things should be moving along. I don't know what the final solution will be, or whether there will be one at all, but I'll try to remember posting here any updates I get.
For completeness sake, I'll say that this matching of changesets between xlink and the parent repo was considered a feature, as the Plastic team thought keeping a clear history matching both repos to be important. However, that's because they see xlinks as a way to develop sub-features of a complete system.
For me, however, xlinks are a way to maintain common libraries between different projects, and for that use case, matching the histories of different projects 1-to-1 in the library repository makes no sense. The library history is unreadable, as it gets cluttered over time with meaningless empty changesets [edit: or changesets and branches that are irrelevant for the library history].