Weisst Du, was Du da tust: https://tools.geofabrik.de/osmi/?view=areas&lon=7.49416&lat=52.79518&zoom=11&opacity=0.95 ?

Das geht auch besser: https://tools.geofabrik.de/osmi/?view=areas&lon=7.71654&lat=52.27516&zoom=15&opacity=0.95&overlays=duplicate_node,single_node_in_way,intersection,intersecting_segments,ways

Bitte sorgfältiger. Flächen können sionst nicht gerender werden:
https://tools.geofabrik.de/osmi/?view=areas&lon=8.78701&lat=54.10286&zoom=11&opacity=0.95

relation/12706939
Welche Art von Grenze soll das sein?

Please fix dismembered Multipolygon
relation/6129941

Den einen Algorithmus gibt es nicht. Vermutlich meinst Du den des ID-Editors. Andere Algorithmen zur Fehlererkennung und -behebung kommen möglicherweise zu anderen Schlüssen, gerade bei widersprüchlichem Tagging. ID gibt bei der Fehlerbehebung dem boundary-tag offensichtlich den Vorrang vor dem type-tag und ändert diesen entsprechend ab, was aber pauschal für eine automatische Reparatur nicht gerechtfertigt ist. Mir geht es darum, dass man der automatischen Korrektur nicht blind, sondern das Ergebnis kritisch hinterfragt.

Den Hinweis auf gute Mappingpraxis will eher auf die Zukunft gerichtet sehen, dass man sich anhand der Kriterien vorher überlegt, ob das eigene Projekt unbedingt in OSM sein muss.

Die inner-Flächen der Relation relation/13705820 (farmland) sind nicht innerhalb der Relationsfläche, da sie überhaupt nicht bzw. nur teilweise (forest, orchard) von der Relationsfläche umgeben sind.

Sieh auch https://tools.geofabrik.de/osmi/?view=areas&lon=7.93193&lat=49.70350&zoom=14&opacity=0.95

Was bringt dich zu der Meinung, die Relation sei falsch definiert? Diese Relation ist lediglich eine Ansammlung von Überresten und Rekonstruktion von Anlagen einer ehemaligen Grenze sowie von nicht mehr sichtbaren Grenzverläufen. Dazu noch eine Anzahl von Knoten ohne tags. Das ist keine boundary-Relation mit geschlossenen Ringen aus outer- und inner ways, die ein Gebiet abgrenzt. Die gehörte eigentlich auch gar nicht in die normale OSM-Datenbank (osm.wiki/DE:Good_practice#Mappe_keine_historische_Ereignisse_und_ehemalige_Objekte).

Nachträglich ist das schwierig zu beschreiben, aber anhand der Relation relation/13692671#map=17/47.29727/15.69673 folgendes: Bei den Relationsmitgliedern hat eines die falsche Rolle. Sowas lässt sich einfach mit dem Validator von JOSM erkennen und es gibt die Möglichkeit, das per Mausclich oder Tastendruck zu reparieren.

Davon abgesehen gibt es keinen vernünftigen Grund, einfache fertige geschlossene Ringe zu zerhacken, um sie dann mittels einer Reation als Bausatz zu hinterlegen. Das macht die ganze Sache unübersichtlich und fehleranfällig.

Außerdem sind Relationen mit nur einem Mitglied (relation/13692670#map=19/47.29629/15.69638) sinnbefreit, denn eine Beziehung = Relation kann nur zwischen mehreren Objekten bestehen.

Bitte nutze den Validator von JOSM um solche Fehler zu vermeiden:

https://tools.geofabrik.de/osmi/?view=areas&lon=13.90630&lat=51.28847&zoom=14&opacity=0.95

Vor allem sind das keine Multipolygone. Multipolygone dienen der Erfassung von Flächen und bestehen aus geschlossenen Ringen ohne Eigenschaften in der Rolle outer bzw. inner als Mitglieder.
relation/13689152
relation/13689153
relation/13688827

Please be aware of existing relations which may affected by jour edits: https://tools.geofabrik.de/osmi/?view=areas&lon=-79.53202&lat=43.65492&zoom=13&opacity=0.95

Die Übernahme in die Datenbank funktioniert ja jetzt momentan mit Version 27 und einer aktuelleren osm2pgsql Version. Ich befürchte nur, dass sich das möglicherweise schon ändert, wenn sich die Sortierung der member in in der Relation ändert. Dann lassen sich u.U. die beiden outer-Ringe nicht mehr eindeutig rekonstruieren, sondern es ergibt sich ein einzelner, sich selbst überschneidender Ringe.
Das ließe sich zuverlässig verhindern, wenn einer von beiden schon als einzelner komplett geschlossener way angelegt ist.

Und jetzt berühren sich die beiden outer-Ringe wieder in 2 Punkten, was das eigentliche Problem ist, weil das nach OGC-Standard bei Polygonen nich erlaubt ist.

Siehe dazu note in way way/193871746 und Kommntare zu changeset/105621654

Was heisst ignoriert? Keine Rückmeldung irgend einer Art?

Anscheinend hat osm2pgsql Swwieigkeiten, aus dem OSM-typischen Geschnipsel eindeutig geschlossene Ringe zu bilden.

In Version 21 (http://overpass-turbo.eu/?Q=%5Bout%3Axml%5D%5Bdate%3A%222021-05-30T00%3A00%3A00Z%22%5D%3Brelation(https://wiki.openstreetmap.org/wiki/Tag:957703)%3B(._%3B%3E%3B)%3Bout%20meta%20qt%3B&C=47.79762;10.38976;15&R) sind Ex- bzw. Enklaven schon als als einfachen Polgon vorgegeben. Funktionierts etwa damit?

Siehe OSM Inspector: https://tools.geofabrik.de/osmi/?view=areas&lon=12.13774&lat=51.50699&zoom=13&opacity=0.95

Was ist hier bitte verbesstert? Ich sehe nur ein kaputtes Multipolygon.

Mit diesem Änderungssatz habe ich nach einen abgebrochenen Versuch der Bereinigung den Zustand der
Version 22 (changeset/105570730) wieder hergestellt. Jetzt habe ich die Relationen so angepasst, wie meiner Meinung nach sein sollten. Die Lage ist etwas verzwickt mit Ex- bzw. Enklaven in den benachbarten Gemeinden. Die Zuordnung kanm man Bayernatlas erkennen, indem man in die entsprechende Fläche klickt: https://v.bayern.de/DYWKg

Why did you remove the from-members fom relations relation/7044818 and relation/7044819

Hiding accessibility in name tags is not adequate. It is not analyzable by routing engines and other tools.

Please use proper access tags. The name tag is for names only:
osm.wiki/Names#Name_is_the_name_only
osm.wiki/Names#Names_are_not_for_descriptions

Use routes for mapping trails:
osm.wiki/Relation:route
snowmobile=*

And what's obout the dismembered relations for boundaries and water bodies?