Hello "Verney Fields" and welcome to OpenStreetMap.
OSM is a map of things as the really exist in the real world. It's not a vehicle for political argument or "satire".
You're welcome to continue with OSM as long as you map sensibly, If you don't, you'll be prevented from doing so permanently.
Best Regards,
Andy Townsend, on behalf of OSM's Data Working Group.

Thanks - from memory relation/109767/history / https://overpass-turbo.eu/s/1VAb was never signed as NCN62 but was signed as TPT, so leaving it in just relation/4139162 makes sense.

Hello,
One more thing - you've deleted some things that were previously mapped here such as the Co-Op way/158249037/history and remapped it with far less detail at way/1341830684 . Was the previous detail wrong, or should the old tags be transferred to the new building?
Best Regards,
Andy

Hello,
In this changeset you've deleted way/26579103 , which was a cycleway between the bridge over the railway and Market Street. Is that really no longer there? If not, how does the Isle of Anglesey Coast Path join now? You can see that there are two gaps at relation/374890#map=19/53.309924/-4.632099 .
Best Regards,
Andy

@lberges Please do discuss this in the forum. You know what will happen if you don't.

Hello fwonp,
You've added a house here, yet the changeset comment is "swimming"?
I'm confused?
Best Regards,
Andy

Thanks!

The previous value was a bit odd (comma rather than a semicolon) and so needed changing to something.
What is the actual correct value probably depends on survey local knowledge or really good photos.
If it was me and it looks like "mostly mud" then I'd use "mud" for the surface value; I'd only use a semicolon-separated value if it really was a mix of the two.

If the surface here is "mostly mud" then I'd probably have gone with "surface=mud" (and "sand" for "mostly sand" nearby).
If mutiple values are needed, then senicolons are usually used as separators.
Data consumers have the choice whether to use the whole value or just the part up to the semicolon.
You can see which tag values are used by which projects by looking at the "projects" tag at taginfo.osm.org.
The maps I produce show tidal and non-tidal mud and sand as different patterns, and because "tidalflat" is a bit vague, use the surface value.
Generally speaking, if a rarely-used value can be obviously replaced with another value that means exactly the same thing it makes sense to do so, but it doesn't really make sense to remove a rare value altogether.
Presumably you've had a look at different sets of imagery here and already have an idea that "yes, that's more like mud than sand" (or vice versa) so should be in a position to decide which - or if it is not clear, "surface=mud;sand".

Hello on way/724756959/history you've moved the surface tag. Would "surface=mud", "surface=sand", or even "surface=mud;sand" work here?
Best Regards,
Andy

It is still listed at https://www.londis.co.uk/our-stores/strensall-service-station , but that might just be a matter of time.

One thing that I noticed when doing this update was that some paths are signed on the ground as public footpaths but don't appear at https://map.atownsend.org.uk/maps/map/map.html#16/53.7489/-2.0246/H/P (data from local councils via Rowmaps). I'm assuming that on-the-ground signage trumps data that local authorities.

This section removed some dupicate abandoned railway that now forms Nidderdale Greenway.
Most of the western section of Nidderdale Greenway is clearly exactly on the old railway alignment and was more accurate than the duplicate former railway that had been added from some iffy old map.

Thanks for fixing!

and for completeness, the "missing" polygons jumped back into the database this morning - for example the historic Anglican parishes:

1228a1229
> -10742937 | St. Peter's Parish
1368a1370
> -10709157 | Stillorgan Parish
1416a1419
> -8851833 | Stillorgan CofI Parish 1900
1469a1473
> -8811305 | Taney Parish 1900
1603c1607
< (1600 rows)
---
> (1604 rows)

OK, as requested by PM, I've reverted this changeset and the related one before it.
If you want to see the geometry of the now reverted ways, you can do that with overpass, for example https://overpass-turbo.eu/s/1Vc4 shows way/1339929485 as it was a couple of hours ago.

It looks like this has change might have broken some multipolygons (you can see them in the JOSM validator):

civil parishes
< -2235928 | Taney
< -2234306 | Stillorgan

Elsewhere these townlands were no longer valid multipolygons this morning:

< -4622479 | Rocheshill
< -4592163 | Ballinclea
< -2195324 | Mount Merrion
< (55675 rows)
---
> (55672 rows)

and these electoral districts:
< -12495187 | Stillorgan ED
< -12491366 | Dundrum ED (1911)

and these Anglican parishes:
< -10742937 | St. Peter's Parish
< -10709157 | Stillorgan Parish
< -8851833 | Stillorgan CofI Parish 1900
< -8811305 | Taney Parish 1900

See comment on changeset/159793833 - in the case of way/1334140977/history at least what would have made most sense to preserve the "railway=abandoned" tag on e.g. way/1334140978 , the track that is there now. The influence of the railway remains on what is there now; railway=abandoned communicates that to current data users.
In addition to that, it also makes sense to contribute "how things used to be" as actual railways to OpenHistoricalMap.

While way/1334140977/history was pretty obviously an abandoned railway based on the imagery, what would have made most sense here would have been to apply the railway=abandoned (or similar) tag to the extant track here way/1334140978 . Your changeset comment here is factually inaccurate here in that there IS still a trace of it in OSM. It didn't make sense for the other mapper to duplicate the way in OSM, but to just delete the duplicate without preserving the tags doesn't make sense.

OK, relation/14510149 is a valid relation again. https://overpass-turbo.eu/s/1V39 will show the relation at this point in time. Your version, which had all the duplication in it, was https://overpass-turbo.eu/s/1V38 . I'd expect that you'll want to add existing ways to the relation to do that, but you'll need to make sure that you don't duplicate any geometry of the current relation, which will break it as a multipolygon.