There is something incredibly illogical in the creation of a multipolygon whose outer polygon is natural=bay and the inner polygon of natural=coastline. The bays represent the minor notion of small part of the sea. The coastline represents the essential notion of border between the sea and the land. The only multipolygon, in the logical sense of the term to which the coastline belongs, is the earth! The rest, in Corsican in the text is monta sega, an incredible claim of the cartographer to dominate the world!
I think I just came across the definitive answer to my question : https://help.openstreetmap.org/questions/65910/should-islandsislets-be-the-inner-border-of-naturalbay-areas?
Frankly, I would prefer to convert the multipolygon into a node because I think it would be better in all but I am too beginner to take this initiative without your advice: Yes or No?
Better still, would someone with experience want to do it properly?
Actually, it is easy to “convert” the big multipolygon to a node. The only problem is, the original mapper might be angry if you do it without a consultation before proceeding. He did a lot of work to create it and likely still thinks it is a good idea. So while this method will work, I don’t want to take the responsibility for actually doing it. If it was in my neighborhood (Alaska, Thailand) I would reach out to mappers I’m familiar with before doing anything.
Like the person who created the Golfe d’Ajacci multipolygon, I once thought mapping bays as multipolygons made sense. My goal was to let the rendering software figure out where the centroid of the area was located rather than an arbitrarily placed node. But my thinking has changed. I started a long thread in the Tagging group about this topic a couple of years ago. Anyway, the added complexity for newer mappers is one big reason I abandoned my scheme. Your issue is a case in defense of that decision.
Should you get agreement with the original mapper(s), deleting the Relation is easy. But before proceeding, make a list of the tags and values already assigned, the name:ar, Wikidata value, etc. because there’s no way to copy them to the new node you will create. Place a node somewhere in the middle of the bay and assign those tags to it. Now you’re ready.
I don’t know how to do this using the iD Editor or Potlatch so my steps will only work inside JOSM.
In JOSM you merely select the Golfe d’Ajacci multipolygon, click the Edit button, then once the Edit Relation window opens, just click the button that looks like a trash can at the top of the Relation Editor. You will get a warning that the operation cannot be undone. Continue. The Relation is gone. No ways are deleted. All the pieces of coastline will still be present and tagged with natural=coastline. The other relations that also include those pieces of coastline are unaffected. By the way, those pieces of coastline are included in many boundaries. I’ve never seen anything like that before.
Hope this helps
Dave
If you map the bay as a node, there is loss of information, no in/out like with a polygon, so you cannot tell if you are in the bay or not.
Yes, that is one argument for the use of a multipolygon and it’s one that was discussed at length in the thread I referred to. In those prior discussions, that loss of information was not as important an issue as the complexity one. In the end, it’s up to the mappers involved to decide what’s best in any given situation.
I will find that discussion later if you’re interested. I can’t do it immediately as I have an appointment.
Here are two discussions from the Tagging listserv that are relevant to this one:
https://lists.openstreetmap.org/pipermail/tagging/2019-April/044743.html
I think you’ll find the next one particularly interesting as it involves comments from some of OSM’s big contributors, Frederik Ramm among them. It’s a contentious conversation but worth your time:
Using multipolygons to map large bays in Alaska
https://lists.openstreetmap.org/pipermail/tagging/2018-November/040911.html
From the beginning I am in private contact with the creator of this multipolygon. He (she ?) is someone courteous, convinced and an educator. It actually helped me better understand all the ins and outs. He does not wish to participate in this thread because of the language barrier.
Once all the arguments have been spread out, we do not select the sames aguments and remain in antagonistic positions. This is not the first time that one of his polygon is deleted, but it is the first time that somebody ask his opinion!
In a location in which I am preparing to make a big effort I consider myself justified in making this replacement.
There is however an real argument against. Here is the illustration: https://www.openstreetmap.org/node/7367542817#map=14/45.0577/-3.3279 .
It seems that the polygon is the only way to appreciate the difference in importance between the Bay of Biscay and a tiny cove in Corsica because the key:nature=bay cannot be calibrated. Do you have a idea to help this problem?
Actually, in your argument example, user:woodpeck did exactly what you propose to do in your situation. He deleted a huge multipolygon that outlined the Bay of Biscay and replaced it with a node. The reason he did it was to simplify the OSM data structure and to make editing other objects in the bay easier.
Woodpeck, by the way, is an account used by a major OSM guru, Frederik Ramm, that I mentioned above. He has argued strongly AGAINST using multipolygons to map bays. He would definitely support your move to get rid of that big multipolygon.
You are also correct when you say that by using nodes to represent large bays, the difference in relative size compared to smaller bays is lost. Smaller bays inside the Golfe d’Ajacci will have the same text size when rendered and will therefore appear to be just as important as the bigger bay that surrounds them. There is no way at present to, as you say, “calibrate” the size. That’s the trade-off one must make when using a simple node to represent a large bay. You can’t have it both ways.
Every model is a simplification of reality, simplified so that it represents the characteristics that we need to take into account so that the model can give answers.
Simplifications have to be properly balanced to continue representing reality. If we oversimplify, as is what (in this case) arises and was done, we will not be able to answer some questions, such as where is outside or inside a bay.
The territorial extension of a bay is clearly a geographic data. That for simplicity it is feasible to map it as a node, or because no one has yet mapped it as a polygon does not imply that other collaborators have the possibility and the need to do so, they are prevented from doing so, and that the bays already mapped as polygons are changed to node as it was done in that case. There should be room in OSM for this type of data.
This polygon, simple, marking the limit of the gulf, away from any risk of emergence of an inner coastline before a good time, large enough to induce a visible text, would it be suitable?
You need to read the threads I offered in one of my replies. Your arguments are good but they’ve all been argued before in those conversations. The same with the solution of using an approximate shape that would give navigators, for instance, a solid indication that they were inside of or outside of a bay or strait.
In the case of straits, (see the second thread) I argued that it would be important for a navigator or pilot of a ship to know if he was in the Shelikof Strait or in a sheltering bay adjoining it and that this situation could be better treated by using a rough shape like your polygon Philippe. People opposed pointed out that the OSM method of mapping a strait is with a line, a string of points that roughly follows the center of the strait. I didn’t like that idea at all. A string of points does nothing but put a name on the map — it tells you nothing about geographical extent. Also, a 4-sided multipolygon is a simple structure to maintain. I went ahead and mapped it as an area described by a multipolygon.
Shelikof Strait https://www.openstreetmap.org/relation/8910719
(The Shelikof Strait is a passage between Kodiak Island and the Alaska mainland that is a very dangerous area)
The idea of representing a bay or strait with a multipolygon might seem the best method but I can tell you for sure that if you use one in a situation like your gulf, it is subject to removal by the OSM high command. I decided to use a simple multipolygon for several straits in Alaska but decided not to use multipolygons as a device to make big bays stand out above smaller ones because of the complexity issues, both in the data structures and for maintenance afterward. And the fact that they might be removed by Mr. Ramm (user:woodpeck)
Cheers,
Dave
Thank you for your great patience!
And this possibility: https://www.openstreetmap.org/way/797372132 ?
As an aside, I’m really surprised that renders at all - hats off to the OSM Carto people! 
Well, it’s an interesting experiment but of course it wouldn’t work at all for a long narrow bay like a fjord.
I hope this conversation has been helpful. Good luck and keep mapping!
Dave
Thank you all 
Put into practice, critics welcome : https://www.openstreetmap.org/way/674848804#map=12/41.8179/8.6222
I don’t recommend this approach. I’m sure you will draw criticism from other mappers as well.
What amazes me is that the name of the gulf renders so large and appears in the same place as the other one. I suspect that’s because the rendering hasn’t yet “caught up” with your recent edit.
I strongly recommend using a node to represent the Golfe d’Ajaccio.
Thank you for this clarification.
My concern is only to liberate the basic notion of “natural = coastline”. I can thus focus on my project which includes to correct the coastline reality. For this, a simple node also suits.
I tried with this approach to keep the drawing of the border of the Gulf and a significant rendering. These are concerns that have been expressed. Lets at least a few days to touch the rendering and hear the reactions. Afterwards, switching to a single node if this is the consensus to be respected will be a formality. This is not binding.
I suggest mapping a way across the water marking the outer bounds of the bay, tagged with natural=bay and also a node tagged with natural=bay, name,etc in the most suitable location within the bay.
This method defines the boundaries of any bays simply without tangling with the coastline and gives a reasonable label location.
Double advantage: it’s cognitivement relevant and if the mad Guru removes the border line, there will remain a (very small) trace for the archaeologists 
For the exterior path I preferred to conceptualize it in two nodes.
https://www.openstreetmap.org/node/7463035976
TY
Not sure, but adding both way and node seems to break the “one feature, one element rule”.
Maybe you can solve this if you put the way (role “outer”) and the node (role “label”) in a “bay” relation, like with admin boundaries.
Anyway, the natural=bay wiki says about rendering: