Thank you very much for providing this detailed insight into your workflow. 

You mentioned how overlapping edges of ways would be challenging to unglue, but I don't see how this would be true. With a simple alt + left-click on the edge in JOSM you can easily select the next object in cases of overlap. It's not like you'll ever see five or more ways with overlapping edges, so I don't see how this would be a limiting factor to your (or anyone’s workflow).

On the other hand, these very large multipolygons are an issue for many mappers and data users alike. This method of mapping violates the "One feature, one OSM element" principle we have, which dictates that each field should be represented by its own polygon, where you have mapped all fields together as a single object. This gives data analysts the wrong idea that there are only a handful of landuse polygons mapped on the entire island, while the map clearly shows thousands of polygons. It’s also a substantial problem for other all other OSM mappers, who have never mapped like this, might fail to understand the complexity of these multipolygons and will undoubtly have trouble loading the data into their editors. 

We do have a technical limit imposed on the number of members in a relation, although you’re not likely to hit that anytime soon: https://wiki.openstreetmap.org/wiki/Relation#Size. This Wiki page also recommends keeping relations small whenever possible. 

My suggestion to you is that you change your mapping style to work with lines and areas that may have overlapping edges. This will improve the map for users and will make it easier for other mappers to contribute. 

I (together with several mappers that I spoke to on Discord) would also like to see the existing multipolygons being converted into closed ways with the exception of cases where multipolygons are strictly necessary. If this is technically challenging for you, I’ll be happy to lend a hand, as I have experience with reconstructing large and complex multipolygons.

Let me know what you think of this, so we can figure out a plan that can satisfy everyone.

Best regards,

Casper