Interesting case you have found.
Visibility and usability aside, I believe that the opencpn representation conforms to S52 standards better that the CMapECS.
In S52 speak, SLCONS (Shoreline Construction) objects are symbolized with a line outline, the pattern of which depends on the condition or attribute of the object. In Subic Bay, this object is "Under construction", so a thin dashed line is used. In S52, there is no area symbolization defined for SLCONS, so that it takes the area symbolization of the underlying DEPARE or LNDARE object.
So, this dataset cannot tell us if the area in question is dry or not. The best we can deduce is that it was flooded at the time the survey
Presumably, a newer dataset would give this area as a LNDARE object, surrounded by a "finished" SLCONS.
As an aside, I don't know how to interpret depth
contours and soundings in an area that looks dry, or at least is symbolized the same color as land.
Now, to the real world. I believe CMapECS is wrong in this instance. I hesitate to change the symbolization rules in opencpn for a class of objects in an effort to match CMapECS at one point on one chart. Changes could then propagate anywhere in the world without the user being aware of the issues involved.
As always, the choice of navigational tool is up to the individual navigator.....