Good ol’ history=* enters the chat.
Ideally software could do this analysis automatically so we wouldn’t need to manually. Unfortunately, changesets aren’t quite the right level of abstraction, since a changeset can consist of multiple uploads (common with JOSM). Beyond that, there’s always the possibility of splitting, then doing all sorts of stuff to the affected elements, and only then uploading. None of those intermediate actions will be saved in the changeset, unless you’re looking at an ancient changeset that was saved multiple times using Potlatch 1’s live mode (and subsequently coalesced into a single changeset anyways).
This situation is reminiscent of Git: it doesn’t explicitly track file moves or renames, so that the “Renamed from” indicator in GitHub is based solely on diffing two files that were added and removed. If you move the file, change it enough, and only then commit your changes, Git will record it as a deletion of the old file and addition of an unrelated new file. In other words, it doesn’t track the action of moving, only the aftermath, which can be watered down.
When it comes to tracking changes across renames, Git is less reliable than Subversion and Perforce but still more helpful than CVS. Still the software development world largely gets by with it.
In OSMUS Slack, @Mateusz_Konieczny shared a rough Python script for detecting way splits. Despite the caveats, this kind of detection can still be useful to OSM archaeologists. It would be cool to see this functionality work its way into something like augmented diffs, and maybe even the main site’s element history view if we could set appropriate expectations.
This occasionally comes up as a limitation even outside the context of change tracking. Selfishly as a mapper, I would love for the data model to support inverse relations for situations where the child elements are very weakly related to each other, ignoring the disruption that a new element type could cause throughout the software ecosystem. But if we also solve the problem of transcluding unversioned elements by bumping versions across the board, wouldn’t we potentially end up with massive version inflation in some cases?