Lee Carré (2021-11-20 14:57:48+00:00): Since I, evidently, haven't had opportunity to finish drafting my full response (it became quite lengthy; I may actually publish it as a diary entry and simply link to it), hopefully this will suffice until I do. 

Firstly, this sounds like http://wiki.osm.org/wiki/Tagging_for_the_renderer which is to be avoided. 

“[the tagging] was messing up some of the address labels in certain programmes”
Then that renderer (or address parser / generator) should be fixed, instead of compromising data, especially since there are a multitude of ways to render the same data. Data should accurately reflect reality, regardless of how renderers currently handle the tagging (or elements; many don't fully handle relations, especially for routing). Renderers should then adapt to handle said accurate tagging. 

To do otherwise is to inhibit improvement of data-parsers (renderers, etc.). 

“messing up some of the address labels”
However, incase it really is a data (non-rendering) issue; how so? If you submitted a bug-report, then a link to that might suffice. 

“the borough tag was making these places rank higher”
Places should be tagged based on what they actually are, not how any particular renderer may present them (see above). The map is the database of tagged nodes, not the tileset generated by one particular renderer. Many people use the data in a variety of ways, so it's unwise to presume which renderer (if any) they might be using. 

Ranking (if that concept is relevant; it isn't always) is derived from the semantic meaning of the values, not how it's rendered. Renderers should match / reflect said semantic meaning. If they don't, then file avg reports to have them fixed. 

“ensure the parish is always prioritised”
What, precisely, do you mean by prioritised or priority? 

Hierarchy (in this context / scenario) can be (and is, in OSM) derived by the relationship between which elements enclose others. 

“Have left First Tower as a suburb though since it isn't really in town.”
While I agree that it doesn't seem to qualify as a town in its own right (but, then, what's the consensus definition of what does qualify? Hence raising the point that it should be discussed), it's not a suburb (of a(nother) town), either. 

“Parish centres, as well as other important centres (Maufant, St Aubin etc.) should be marked with a village tag.”
Why? Only actual villages proper should be tagged place=village. Other places of importance should be tagged distinctly. Such as being selected as the admin_centre of an admin relation. 

Hence why I see the need to discuss such things, to figure out sensible (semantic, machine-readable) ways of properly marking (tagging) the somewhat unique features of a small island, to have a well-thought-out scheme which is applied consistently, to be successful in presenting a case to developers of data-parsers (renderers, etc.) to handle such a scheme (which may well involve a per-nation conditional). Its likely that they don't know about Jersey's oddities and the challenges that poses, and probably guess that the rules for the mainland apply here. For example, note that the group of islands to our SE (I forget which name is for which group, nevermind being able to spell it correctly, without looking it up, while using a limited device) are mapped as being French territory, rather than ours. Though, perhaps that simply means that they're disputed. My point; unless developers have the necessary info (from locals who even know of OSM) then they'll have to make assumptions based on guesswork. Yet, in my experience, many are receptive to learning about places where the assumed rules don't apply, and what the actual situation is, and are willing to do the necessary work to make an exception / conditional for such places. 

“St Helier, St Saviour and St Brelade with a town tag due to their relative importances.”
Why? Parishes aren't towns. Only actual towns proper should be tagged place=town . 

Importance can & should be derived from semantic hierarchy. Else, there needs to be devised a method of tagging places on the small scale of this rock. 

Just as it would be incorrect (even if convenient) to mark parishes as states, since they're not states. 

For now, maybe simply place=parish (this is one of the advantages of textual key:value pairs; new values can be set whenever needed). Did you check what less-common values exist in TagInfo? If place=parish suddenly appeared, and only here, then that would get some people (developers & influential mappers) thinking & enquiring, rather than continuing to assume that their guesses are valid. 

Think beyond renderers; when querying the count of towns in Jersey, the answer should be 1, not 13. 

“parishes are admin level 8, vignatines/cuillettes level 9”
Why, precisely?
What's at level 3-7? (If I recall, level 2 is for nations; else if it's level 3 then my previous question would be for levels 4-7.) 

“the goal should be that visualisations prioritise parish names over anything else”
Why the focus on visualisations (by which I assume you mean graphical renderings)? 

I strongly disagree, based on said focus. It also goes against OSM policy & technical-soundness (from which policy seems to be derived). 

The goal is an accurate libre map (which is the dataset of tagged elements). How that's rendered is a distinct concern. There are several renderers, and many different renderings, which focus on different features (some deliberately omit labels). So, data accuracy is paramount to not hinder that. Multiple renderings from the same data is hugely beneficial; as one (major) example, it avoids the problem of trying to design a single rendering to please everyone; different renderings for different target-audiences. 

Take a look at the layers tab on the website; compare how some of those are significantly different to OSM Carto (the default). All rendered from the same data. There are quite a few others which are radically different.
Several use-cases involve no rendering. 

So, while I do agree that, regardless of appearance, in a nested list denoting the hierarchy of the likes of parish etc., that parishes are (locally) quite high (but under the island & bailiwick, at least), and that common-use renderings should reflect said hierarchy (but how they do that is another question; there are several ways), I absolutely disagree that data should be corrupted to pander to any particular renderer. That's backward, and significantly reduces the value of the data (and thus OSM). 

Renders are to be slaves to data, not the inverse. Don't treat them as invariable, and to be worked around. Help improve them by bringing problems to the attention of their developers; that benefits everyone, and achieves the best of both (accurate data, representative renderings). 

What you see on orm.org is merely there for convenience (so that the minimum requirement is only a browser). It's certainly not the best way to use the map. Many folks seldom look at the OSM Carto rendering, including for day-to-day usage (e.g. reference & navigation). Consider how popular OsmAnd is; that downloads the map data and renders it locally (for a whole variety of reasons; many more features (e.g. searching (offline) are possible that way). You've used StreetComplete, which uses yet another rendering still. 

To try to achieve ideal rendering, in each renderer, without changing any of them, all by data-fiddling, will be impossible & futile. 

Start with accurate data. If renderers handle it badly, then address THAT problem (of the renderer). 

Seriously; read http://wiki.osm.org/wiki/Tagging_for_the_renderer since it gives examples and somewhat explains (though, not well about WHY, but I'll edit that when I can). 

If you have particular questions (since the concepts are abstract, and it's within my realm of expertise) then fire away and I'll do my best to address them. 

That's actually why my draft response became lengthy; I attempted to give a crash-course on why the sensible way is such, and a bit of the history of the problems it avoids. 

I suspect that you may have picked up some misconceptions from certain others who focus on the default rendering regardless of the data. 

Hopefully this provides enough food for thought.