About a month ago I fixed up a number of wiki problems flagged by Mateusz’s validator, including moving a number of Wikidata/Wikipedia tags from bounded localities to the place node of the populated place that the Wikipedia article was about.
I received a couple of changeset comments asking about these (12) and I responded with an explanation. In return I got told that the Wikidata items apply to the bounded locality. Turns out that somebody had linked to the Wikidata item to both the populated place and the bounded locality. Given that Wikidata is a hot mess of contradiction and confusion I wasn’t surprised. So, I created new Wikidata items for the two bounded localities (Q116038452Q116039373), fixed the items for the two populated places, and added the new items to the admin boundaries. I thought that would settle the matter.
However, I then received a note asking if I was planning to do this for all of the admin boundaries, at which point I twigged to the fact that this is part of some sort of organised mapping activity to import these things into OSM.
Before I respond to the last message I want to find out what the communities views are on this. Am I overthinking this? Is there any problem with the bounded localities being linked to Wikipedia articles about the populated place with the same name rather than linking to the place node?
I am sorry that you haven’t gotten a response so far. I would recommend joining the Wikimaps Telegram group, where people who are interested in the OSM-Wikimedia (and especially OSM-Wikidata) interface hang out.
Responding to your specific question — I don’t think you’re overthinking things. It is well known that Wikidata conflates items for various levels of geographic entities, and splitting them is the right call. I’m glad you’re considering doing so!
One way to make such splits less painful for data consumers is to make sure that any relevant data is carried over to the new items.
First of all, the translations of the names in all languages need to be copied over to the new Wikidata items.
Second, links from OSM to Wikipedia need to be added. The Frankland River relation now only links a Wikidata item without sitelinks to Wikipedia; it should also have a link to all the Wikipedia articles previously linked by the linked item, given the two concepts are merged on Wikipedia. The Frankland River node has a link to the English Wikipedia article only but not to the other languages (this may be fine).
Third, links from Wikipedia to OSM need to somehow be handled. Linking the node is clearly not what is needed for the Wikipedia article, as you need to zoom out to get an idea of the place. Linking the relation is an easy way to zoom the map correctly and show both the boundaries and the place name with a single URL. Is there a way to link the node and have osm.org also show the boundary and zoom in correctly? If not, the link to the node needs to be supplemented by a link to the relation.
Fourth, and more generally, Wikipedia and other consumers of the data which previously used the item to pull up data about the map of the area need to be provided the new way of accessing the data. I’m not sure how to handle this on the English Wikipedia in general, but in this specific case the infobox allowed to specify a new Wikidata ID. Given this is a common need it would be best for the Wikidata item to provide this kind of preferred map URL to avoid reducing the usefulness of the Wikidata items: maybe a new property is needed?
The English Wikipedia infobox template could be improved to automatically fall back to a contains settlement (P1383) statement to make this more automated. The Wikimedia Commons infobox template has smarts like this to deal with category items and such. But in the case of Manypeaks, the Wikipedia article is linked to the settlement, and I’m not sure if there is any inverse to the contains settlement property. Maybe the two items could link to each other using said to be the same as (P460)?