I see many possible solutions. Two of them are:
1. At the moment multipolygons are cut into pieces just after reading from the input file. The first solution would not move that but the multipolygon code does the cutting for each resolution and tags the result with mkgmap:resolution=N. So there will be a copy of each polygon for each resolution. The style converter checks this tag and filters out the objects that does not match this resolution. The mp cutting code is changed in such a way that it uses the RoundCoordsFilter to check if a polygon is visible in the given resolution. If not it is not used in this resolution.
This variant seems to be quite easy to implement and gives a good impression if that improves the whole story. It is not optimal due to the high number of additional polygons that must be kept in memory. But for a prototyping test it seems to be great.
Yes, that sounds like a good idea for the start. I also have some ideas how to improve the cutOutInnerPolygons() method.
2. The mp cut algorithm could be moved to the resolution dependant processing of mkgmap. That's somewhere between the StyledConverter and the subdivision splitting. This is a bit cleaner but I am not sure how many effort this needs.
Probably a lot more, but maybe I change my mind when I know the code a bit better.
I have no idea how to use a TYP file to avoid such problems. The algorithm to decide if a mixed are should be displayed as sea or land is the resolution dependant mp cut algorithm as described above.
Well, I don't yet have an idea how to handle the case when many small islands cover - lets say - 70% of the area, but all of them are too small to be displayed. I fear we will only display see in that case. Anyhow, this problem has to be solved later. Gerd