My proposal for areas is the same one as the one made by Sanderd17 https://wiki.openstreetmap.org/wiki/User:Sanderd17/Areas which is based on coastlines.
Remove the ring declarations. We don't really need them and without them, we can reuse the implementation of relations. Now the database needs no new kind of an object as an area is just an ordered relation as far as the database storage is concerned. Only the API needs to be changed. On the user side of the API an area is entirely different to a relation and they cannot be intermixed and on the database side areas are just ordered relations with a special internal tag.
The difference to coastlines is that the tag natural=coastline is replaced by a relation membership and that ways having the wrong direction may be used without reverting them by using the role "reversed".
Software no longer needs to work on three totally different concepts of areas. Editors no longer need complicated rules to find out if it's an area or not or even both. It becomes possible to work on partially loaded area data and to render it.
The editors and others programs uploading to the API are responsible for uploading only geometrically correct areas. They should neither expect the API to accept bad areas nor expect the API to do some or all checks.
This new API is only an extension of the old one and the changes can be done without outage. Programs using the API can be extended to use the new API functions without big changes to the existing software parts. After API and software changes are done, a bot may be used to convert all areas which are known to be without errors into the new data structure. It's not necessary to convert areas with problems or potential problems. The mappers can look up the remaining areas and either convert them themselves or just make them good enough for automatic conversion. In the end, type=multipolygon and area=yes/no become deprecated.