The Future of Areas/Issues for Solutions
Proposed solutions should address many different issues that all have to be thought through before a solution can be chosen.
Problems
Any solution should address the problems identified for the current system. Ideally, of course, it should solve all of them. But thats unlikely. But we have to think through all problems and evaluate whether a solution makes it better or worse.
Mapper
Solutions must be conceptually simple. If the average mapper is not able to understand what he is supposed to do to enter or use an area, the solution will not fly.
Software
Proposed solutions should also address the question of what software changes will be necessary in the different parts of the OpenStreetMap ecosystem:
Process
The best solution is not usable if there is no way of getting there. So proposals should address the question of how to get from where we are to the full implementation of the solution. Can the solution be implemented step by step? What parts will be automated, what parts need manual intervention?
It is probably not possible to have a specific date where all software has to change suddenly. Is there some grace period where old and new versions can co-exist?
Polygon Sizes
The solution must work with (multi)-polygons of any size. It must be possible to create an area for a small building with four corners. And it must be possible to create polygons with hundreds of thousands of nodes on their border for countries, etc. It might not be possible to do that with once construct, maybe there will always be two ways to create polygons, one for small ones, and one for large ones. But then it should be possible to change one into the other and for normal mappers they should be equally easy to handle.
Real Multipolygons
The solution must support real multipolygons, ie. polygons with several outer and inner rings. Many countries for instance have several parts (such as outlying islands), some have holes (such as the hole in Rome, Italy, where the Vatican is).
Assembling Multipolygon Geometries
It must be easy to assemble multipolygon geometries from their constituent parts. Fewer indirections from one OSM object to another makes that easier. If part of the multipolygon changes (such as when a node moves), it should be easy to re-create that multipolygon geometry just from the change file.
Routing Over Areas
Routing over areas should be possible. Generally routing works along roads (ie. ways), but sometimes there is not a simple way but an area (park, city square) that you want to route over. Thats especially important for pedestrian routing.
Spatial queries
It would be nice to be able to perform a very common spatial query with OSM polygons "Within which polygon did I click on a map". None of the proposed solutions seem to support it at the database level.